when i run eselect compiler update, it removes all of the symlinks to gcc throughout the system. this makes python, portage, and several other applications that use libstdc++ to die. re-adding the /usr/lib/gcc/[arch]/[gcc-version] to /ect/ld.so.conf and running ldconfig. independant of gcc version. Reproducible: Always Steps to Reproduce:
what gcc profiles do you have activated? What's the output of 'eselect compiler list'?
i only have one activated, 4.0.2, the output is correct, same as gcc-config. cant tell you exacts casue i deleted it, and reverted back to the old one to have a working system.
Could you show your /etc/eselect/compiler/<your compiler>? I personally ended up writing my own one since a) it didn't automatically create a working one for gcc 4.0.2, only a semi-working one for gcc 3.4.4 b) toolchain.eclass doesn't create a file with the correct format yet looks like this now:[global] version=x86_64-pc-linux-gnu-4.0.2 binpath=/usr/x86_64-pc-linux-gnu/gcc-bin/4.0.2 manpath=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.0.2/man infopath=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.0.2/info stdcxx_incdir=g++-v3 alias_cc=gcc alias_g77=gfortran [x86-hardened] ctarget=i686-pc-linux-gnu ldpath=/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2:/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/32 cflags=-m32 -L/emul/linux/x86/lib -L/emul/linux/x86/usr/lib [...etc...] [amd64-hardenednopiessp] ctarget=x86_64-pc-linux-gnu ldpath=/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2:/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/32 specs=/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/hardenednopiessp.specs I had to add the 32-bit gcc-lib path so that it would also get added to ld.so.conf when the 64-bit profile is selected so that 32-bit programs can find their libstdc++.so.6
You shouldn't add the 32bit libpath to the 64bit compiler profile. If you activate an x86 compiler, it'll be added to LDPATH in /etc/env.d/05compiler. toolchain.eclass creates them correctly for me: [global] version=x86_64-pc-linux-gnu-4.0.2 binpath=/usr/x86_64-pc-linux-gnu/gcc-bin/4.0.2 manpath=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.0.2/man infopath=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.0.2/info alias_cc=gcc alias_g77=gfortran [x86-vanilla] ctarget=i686-pc-linux-gnu ldpath=/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/32 cflags=-m32 -L/emul/linux/x86/lib -L/emul/linux/x86/usr/lib [x86-hardenednopiessp] ctarget=i686-pc-linux-gnu ldpath=/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/32 spec=/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/hardenednopiessp.specs cflags=-m32 -L/emul/linux/x86/lib -L/emul/linux/x86/usr/lib [amd64-vanilla] ctarget=x86_64-pc-linux-gnu ldpath=/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2 [amd64-hardenednopiessp] ctarget=x86_64-pc-linux-gnu ldpath=/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2 spec=/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/hardenednopiessp.specs
Oh, I didn't notice that I could select compilers for both x86 and amd64 at the same time. That makes much more sense. Thanks for the hint. toolchain.eclass still has a bug: spec=/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/hardenednopiessp.specs is wrong, compiler-config expects the keyword to be specs: install_conf.c: } else if (strcmp(key, "specs") == 0) { That seems to be the only remaining bug as far as I'm concerned (the chost/ctarget has been fixed).
Great eye. Thanks Christophe. I've committed the fix to toolchain.eclass and also put a sed line in postinst of beta2-r1 which should correct the files already there.
marking fixed...
