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

DJ Lucas dj at linuxfromscratch.org
Sat Aug 6 10:53:38 PDT 2016



On 07/24/2016 06:03 PM, Chris Staub wrote:
> On 07/23/2016 05:25 PM, Bruce Dubbs wrote:
>> DJ Lucas wrote:
>>
>>> 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.

--DJ



More information about the lfs-dev mailing list