Bug 351384 – sys-devel/gcc-config should not enforce CFLAGS_${ABI}

• Product: Gentoo Linux
• Status: RESOLVED LATER

[Description Nathan Phillip Brink (binki) (RETIRED) 2011-01-11 19:05:30 UTC]

Mike states in bug 308373, comment 6 that CFLAGS is being phased out of gcc-config. However, if it is being phased out this process is not visible so I decided to file this bug ;-). To help debug compilation failures under portage-multilib, to fix the interference with ccache such as found in bug 346707, etc., I propose that CFLAGS_${ABI} support be removed from gcc-config.

Demonstration of the current behavior:

ohnobinki@ohnopublishing ~ $ x86_64-pc-linux-gnu-gcc -c test.c
ohnobinki@ohnopublishing ~ $ file test.o
test.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
ohnobinki@ohnopublishing ~ $ 
ohnobinki@ohnopublishing ~ $ CFLAGS_moo=-m32 ABI=moo x86_64-pc-linux-gnu-gcc -c test.c 
ohnobinki@ohnopublishing ~ $ file test.o
test.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped

ohnobinki@ohnopublishing ~ $ gcc-config --version
gcc-config-1.4.1 (r1.10 @ 2009/12/27 16:03:52)



Removing support for enforcing CFLAGS_${ABI} would help portage-multilib users discover and fix packages which disrespect CFLAGS. Currently, some packages compile fine 32-bit binaries but with build.log lines that look like

$ x86_64-pc-linux-gnu-gcc -o src/blah.o -c src/blah.c

and others (whose buildsystems must filter out CFLAGS_x86 or ABI=x86 or both) will produce 64-bit binaries with the same command. I want the above line to _always_ create 64-bit binaries.

[Comment 1 Nathan Phillip Brink (binki) (RETIRED) 2011-01-11 19:31:57 UTC]

Created attachment 259563 [details]
wrapper-1.5.1-no-ABI.patch

With this quick patch, gcc-config ignores CFLAGS_${ABI}:

ohnobinki@ohnopublishing ~ $ CFLAGS_moo=-m32 ABI=moo x86_64-pc-linux-gnu-gcc -c test.c
ohnobinki@ohnopublishing ~ $ file test.o
test.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

[Comment 2 SpanKY 2011-01-16 07:57:10 UTC]

gcc-config needs to retain this behavior for quite a while after things have been phased out.  you need to get ebuilds in tree that use this fixed first, as well as the profiles, as well as any other random crap i cant think of off the top of my head.  only then can we maybe think about changing gcc-config.