I have been trying to get my amd64 system to use the FHS-compliant[1] locations for libraries (32-bit in {,/usr,/usr/local}/lib, 64-bit in {,/usr,/usr/local}/lib64). After removing my {,/usr}/lib symlinks, I created real directories in those locations, then moved everything that is in {,/usr}/lib64 that portage thought was installed into {,/usr}/lib into {,/usr}/lib. I then added the following lines to /etc/make.conf: SYMLINK_LIB="no" LIBDIR_x86="lib" After that, I rebuilt all the packages that installed into {,/usr}/lib32. Everything built properly, with the exception of GCC. GCC itself built fine, but then, in gcc_movelibs() (in toolchain.eclass), I noticed an issue that causes the system to become non-functional. Namely, the eclass attempts to move all the libraries in ${PREFIX}/lib/${MULTIDIR} to ${LIBPATH}/${MULTIDIR}. For the amd64 ABI, this expands to "/usr/lib/." -> "/usr/lib/gcc/${CHOST}/${PV}/.", which ends up moving the 32-bit libs into the 64-bit directory, *after* having moved the 64-bit libs there. Obviously, there is something wrong with this. As I noticed that GCC never installs anything to /usr/lib/32 (which is what ${PREFIX}/lib/${MULTIDIR} is for the x86 ABI), I simply applied the attached patch, which removes that one directory from the list of paths to move things out of. The only other package that has ever been an issue with this is old versions of baselayout and openrc, but there are no issues in the latest ~amd64 versions of each. While there is a patch applied to binutils that hardcodes /lib32, et al. into the linker search path, that patch only ends up *prepending* that to the regular search path, so no modifications were actually needed to binutils. [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64
Created attachment 207780 [details, diff] Patch for toolchain.eclass
Committed after testing in bug 35814. Thanks a ton for the patch! :)
