On Tue, 2020-04-07 at 21:37 -1000, Dean Takemori via lfs-dev wrote: > For x86_64 builds, LFS patches gcc to set the default directory name > for 64-bit libraries to “lib” instead of “lib64” (eg in chapter > 5.5.1, 5.10.1 and 6.25.1) by patching gcc/config/i386/t-linux64 > > But the location of the dynamic linker is left in /lib64, meaning a > “stub directory” /lib64 ends up being created and then a > compatibility symlink added in chapter 6.9.1 > > > Is there any reason to not additionally patch gcc and glibc to have > the x86-64 dynamic linker reside in /lib? > > > Tested with glibc-2.31 and gcc-9.3.0 in the final system (not tested > in the temporary system) : there are three locations to patch; No > /lib64 ends up being created and the compatibility symlink no longer > required. > > gcc: > sed -i -e '/GLIBC_DYNAMIC_LINKER64/s/lib64/lib/' > gcc/config/i386/linux64.h > > glibc: > sed -i 's/lib64/lib/' sysdeps/unix/sysv/linux/x86_64/ldconfig.h > sed -i '/RTLDLIST/s/264/2/' sysdeps/unix/sysv/linux/x86_64/ldd- > rewrite.sed > > It’s possible this has some side-effects or issues with some BLFS > packages (particularly programming/debugging tools), but I have not > run into any in my usage.
I think the main problem is if one installs a binary package. Most likely, it will look for /lib64/ld-linux-x86-64.so.2, or even /lib64/ld-lsb-x86-64.so.3 according to LSB. Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
