[lfs-dev] Killing the /lib64 symlinks (Was: Re: [blfs-dev] [blfs-book] r17603 - in trunk/BOOK: . general/prog introduction/welcome x/installing x/lib)

John Frankish john.frankish at outlook.com
Sun Aug 7 01:17:53 PDT 2016

>>>> That symlink dates back to when 64bit Linux was first introduced to 
>>>> LFS, and made a good deal of sense at the time. The toolchain used 
>>>> to be a PITA WRT changing the default lib search paths. Not so much 
>>>> anymore. We should probably take a look at that on next release 
>>>> cycle, make sure lib is preferred, maybe even drop /lib64 
>>>> completely, even if we don't kill the compatibility symlink (which 
>>>> I'd personally like to see go).
>>> I wouldn't mind seeing the /lib64 symliks go, but I'm not sure 
>>> packages would install properly.  I think thy would just create the 
>>> lib64 directories and lead to some files in /lib and others in /lib64 
>>> even though all the libraries are for 64-bit systems.  This would 
>>> need to be tested.
>>> Note that we create similar symlinks in /opt/xorg.
> Is there any reason we modify the linker configuration for all targets and arch?
> Realistically, we only need to modify gcc/config/i386/linux{,64}.h in >LFS, and even 
> then, only for GLIBC. The gcc/config/linux.h file is only for uclibc and bionic (Android),
> and musl (?) gets redefined in the arch specific >target. Is there any reason to
> continue to modify all of those files in LFS? The sed commands get a lot cleaner
> if we only modify the needed files.
I've built 64-bit LFS a couple of times recently without /lib64, /usr/lib64, /usr/local/lib64 - gcc seems to insist on installing to lib64 and it was quite a struggle to fix this. I seem to remember that I had to edit all of the gcc libs *.la files too.

Once all traces of /lib64 had been removed from gcc, almost all of the LFS and BLFS packages install to /lib without problems.

More information about the lfs-dev mailing list