When building =sys-libs/glibc-2.9_p20081201-r2, I get the following output from the build log: [snip] * Building multilib glibc for ABIs: x86 amd64 * ABI: x86 * CBUILD: x86_64-pc-linux-gnu * CHOST: x86_64-pc-linux-gnu * CTARGET: x86_64-pc-linux-gnu * CBUILD_OPT: i686-pc-linux-gnu * CTARGET_OPT: i686-pc-linux-gnu * CC: * CFLAGS: -O2 -fno-strict-aliasing [snip] * ABI: amd64 * CBUILD: x86_64-pc-linux-gnu * CHOST: x86_64-pc-linux-gnu * CTARGET: x86_64-pc-linux-gnu * CBUILD_OPT: x86_64-pc-linux-gnu * CTARGET_OPT: x86_64-pc-linux-gnu * CC: x86_64-pc-linux-gnu-gcc * CFLAGS: -pipe -g -ggdb -O2 -fno-strict-aliasing The relevant portion of emerge --info CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -g -ggdb" CHOST="x86_64-pc-linux-gnu"
if you want custom x86 flags, then set CFLAGS_x86 the ABI situation is too mucky to make attempts at migrating CFLAGS to CFLAGS_$ABI safe and/or worth the hassle. a real multilib implementation would resolve all of this anyways.
I tried CFLAGS_x86 before filing the bug (and left that fact out in the original report like a moron). It has no effect, as I think it gets overwritten by setup_flags in common.eblit. bnsf glibc # CFLAGS_x86='-pipe -O2 -g -ggdb' emerge -1 glibc A snapshot of some of the top lines from the resulting environment file: CBUILD=x86_64-pc-linux-gnu CBUILD_OPT=x86_64-pc-linux-gnu CDEFINE_amd64=__x86_64__ CDEFINE_default=__unix__ CDEFINE_x86=__i386__ CFLAGS='-pipe -g -ggdb -O2 -fno-strict-aliasing' CFLAGS_BASE='-O2 -pipe -g -ggdb' CFLAGS_default= CFLAGS_x86='-m32 -march=x86_64' CHOST=x86_64-pc-linux-gnu CHOST_amd64=x86_64-pc-linux-gnu CHOST_default=x86_64-pc-linux-gnu CHOST_x86=i686-pc-linux-gnu CPPFLAGS=-U_FORTIFY_SOURCE CROSSCOMPILE_OPTS= CTARGET=x86_64-pc-linux-gnu CTARGET_OPT=x86_64-pc-linux-gnu CTARGET_default=x86_64-pc-linux-gnu CVS_RSH=ssh CXXFLAGS='-pipe -g -ggdb -O2 -fno-strict-aliasing' CXXFLAGS_BASE='-O2 -pipe -g -ggdb' note that -march=x86_64 isn't actually a valid flag for gcc, which seems to cause strip-unsupported-flags to throw out all flags for the x86 ABI build. I'm not sure this is a problem, since SpanKY suggested CFLAGS are supposed to be ignored in this case anyhow, but that seems to be a relatively odd means to an end.
Same here. It removes "-mtune=core2" and replaces "-march=core2" with "-march=i686" for the 32-bit build even though I have: CFLAGS_x86="${CFLAGS_x86} -march=core2" in make.conf. The 64-bit build works correctly though with: CXXFLAGS_amd64="${CXXFLAGS_amd64} -march=core2" It's just the 32-bit build. Nothing serious, since the majority of apps on my system are 64-bit, but still, it looks like a bug :)
that's the correct behaviour. why would you use core2 for x86? it's a 64bit arch.
(In reply to comment #4) > that's the correct behaviour. why would you use core2 for x86? it's a 64bit > arch. I think you're confused. core2 is a CPU, not an arch. -march=core2 has absolutely nothing to do with x86 or 64-bit arches. It instructs the compiler to produce core2 specific code, *not* x86 or 64-bit specific one. So it is not correct behavior. "gcc -m32 -march=core2" is not only valid, but recommended.
The same happens to me when updating my OLPC via chroot on my desktopmachine. It builds a generic glibc instead of a geode optimized one. Might it be necessary, so the code runs on a non-geode processor?
Note: I use GentooXO on a first generation OLPC, so building on my desktop is the only way to get stuff updated which needs more than 256MiB memory for compiling → http://www.gentooxo.org/
*** Bug 327331 has been marked as a duplicate of this bug. ***
probably fixed by this http://sources.gentoo.org/sys-libs/glibc/files/eblits/common.eblit?r1=1.18&r2=1.19
