>>>> 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.
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
