[lfs-dev] Killing the /lib64 symlinks

DJ Lucas dj at linuxfromscratch.org
Sun Aug 7 11:28:40 PDT 2016



On 08/07/2016 03:17 AM, John Frankish 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.
>>
> 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.
>
>

If I'm not mistaken, you were probably seeing only libgcc installing in 
/lib64. That can be partially corrected with the --with-slibdir switch 
(not listed in the top-level configure). Pass1 is still gets something 
from the host, however, and installs only libcc1 to /tools/lib64, pass2 
installs where it should. From today, actually only a few minutes ago:

dj [ /media/lfs ]$ ls -l /tools/lib64/
total 516
-rwxr-xr-x 1 lfs lfs    960 Aug  7 12:18 libcc1.la
lrwxrwxrwx 1 lfs lfs     15 Aug  7 12:18 libcc1.so -> libcc1.so.0.0.0
lrwxrwxrwx 1 lfs lfs     15 Aug  7 12:18 libcc1.so.0 -> libcc1.so.0.0.0
-rwxr-xr-x 1 lfs lfs 523880 Aug  7 12:18 libcc1.so.0.0.0
dj [ /media/lfs ]$ ls -l /tools/lib/libcc*
-rwxr-xr-x 1 lfs lfs    958 Aug  7 13:06 /tools/lib/libcc1.la
lrwxrwxrwx 1 lfs lfs     15 Aug  7 13:06 /tools/lib/libcc1.so -> 
libcc1.so.0.0.0
lrwxrwxrwx 1 lfs lfs     15 Aug  7 13:06 /tools/lib/libcc1.so.0 -> 
libcc1.so.0.0.0
-rwxr-xr-x 1 lfs lfs 650120 Aug  7 13:06 /tools/lib/libcc1.so.0.0.0


--DJ



More information about the lfs-dev mailing list