emerge glibc does not compile. compilation done in a chrooted 32bit environment, from an amd64 one. `emerge -e system` fails on glibc. same behaviour (re)compiling glibc-2.4-r4 doing revdep-rebuild does not helps. other information in the attachments. Reproducible: Always Steps to Reproduce: 1. emerge glibc or 1. emerge -e system Actual Results: glibc fails on compile Expected Results: I'hope to compile
Created attachment 111145 [details] emerge info + emerge log
The new summary is wrong. please change: "both glibc-2.5 and glibc-2.4-r4 fails to build" or something else.
same behaviour booting directly in 32-bit environment. chroot seems to be not related with this issue.
remove -D_FILE_OFFSET_BITS=64 from your CFLAGS
sorry if I reopen the bug, just to precise a particular and to do a question. In my system, glibc-2.4-r4 is correctly compiled with "-D_FILE_OFFSET_BITS=64". s939 ~ # bzcat /var/db/pkg/sys-libs/glibc-2.4-r4/environment.bz2 |grep CFLAGS_BASE=|tail -n2 CFLAGS_BASE='-O2 -march=i686 -fomit-frame-pointer -pipe -D_FILE_OFFSET_BITS=64' CFLAGS_BASE=${CFLAGS_BASE-${CFLAGS}}; May be, the problem arise from the new gcc version, which would be uncompatible with it. anyway, you are rigth. moving the wrong CFLAG, glibc compiles fine. I use -D_FILE_OFFSET_BITS=64 because, some time ago, some programs (such as wget) had problems with long size files. so, that's the question: Today, does make it sense to hold this flag, or you suggest to remove it forever?
Never put -D<something> to define a macro in CFLAGS (for one thing, it breaks gcj). If they go anywhere, it should be CPPFLAGS. As for -D_FILE_OFFSET_BITS=64, if a package failed without it, bug about that package, don't set it globally (it's likely a configure failure for the affected package).
*** Bug 188164 has been marked as a duplicate of this bug. ***
