If you emerge gcc-4.7.4 with EAPI=4, you get libgcc_s.so.1, libgomp.so.1.0.0, libstdc++.so.6.0.17, etc installed at /usr/lib64 rather than /usr/lib/gcc/x86_64-gentoo-linux-musl/4.7.4 on a 64-bit system where LIBDIR=lib and not lib64. Note the CHOST name there. But the same happens on uclibc amd64. Switching back to EAPI=2 and all is saved! I'm not sure the cause is the same but this has been seen before: https://forums.gentoo.org/viewtopic-t-917722.html?sid=b134556349e1fb3520bc7e85cd7004db Reproducible: Always
This may also be related to bug #433161, but I can reproduceably show that switching eapi's fixes/breaks the installation.
I've verified that this also happens on i686. Ie. gcc-4.7.4 with EAPI=4 installs into /usr/lib, while EAPI=2 installs to /usr/lib/gcc/i686-gentoo-linux-musl/4.7.4/.
Definitely not the case here. I don't see anything in src_install/gcc_movelibs that would be EAPI affected...
(In reply to Ryan Hill from comment #3) > Definitely not the case here. I don't see anything in > src_install/gcc_movelibs that would be EAPI affected... I'm not sure what triggered this but I can't reproduce it. It happened in the context of catalyst runs which is a complex environment to debug. I must have made some change. Sorry for the noise.