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