Summary: | sys-libs/glibc ignores user CFLAGS for x86 ABI build with amd64 multilib | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nick Fortino <nfortino> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arne_bab, gentoo, phils, realnc |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Nick Fortino
2009-04-07 02:24:04 UTC
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 |