Glibc installs two linker scripts: /usr/lib/libc.so and /usr/lib/libpthread.so where one can find such entry (example for glibc): GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a AS_NEEDED ( /lib64/ld-linux-x86-64.so.2 ) ) which tells to gcc which library should be in fact linked, in this case /lib/libc.so.6. Problem arise when emerging package with SYSROOT different than / (usually used for CrossCompiling). Then even if proper installation of glibc exists in: * /usr/ntuple/lib/libc.so.6 * /usr/ntuple/usr/lib/libc.so linker after finding entry in the latter will try to link against incompatible /lib/libc.so New gcc accepts option --sysroot=... which solves this problem. From my tests I found that setting CFLAGS/LDFLAGS with --sysroot would solve problem, but it doesn't work always. For example libtool links shared libraries with following command: \$CC -shared ... and doesn't use any of {C,CXX,LD}FLAGS. Thus only proper setting of CC when invoking ./configure (I tested this manually): CC="ntuple-gcc --sysroot=/usr/ntuple/" ./configure solves problem. Unfortunately I could not find proper place in eclass files to change this, I tried to replace line in toolchain-funcs.eclass: CC=$(tc-getBUILD_CC) with CC="$(tc-getBUILD_CC) --sysroot=${SYSROOT}" but it didn't help at all (it also didn't destroy anything, and after checking logs is see that CC was still set without sysroot). I would propose then to consider that if SYSROOT is set or is different than '/' then --sysroot is always set for gcc-4 If you dislike this idea pleas at least give me a hint where I should update my local copy of tree to fix this problem for me. Greetings, Rafal
*** This bug has been marked as a duplicate of bug 446204 ***
