[lfs-dev] Killing the /lib64 symlinks

Martin Ward macros_the_black at ntlworld.com
Sun Aug 7 12:44:07 PDT 2016

On 07/08/16 20:29, William Harrington wrote:

>> On Sat, 6 Aug 2016 12:53:38 -0500
>> DJ Lucas <dj at linuxfromscratch.org> wrote:
>>> 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
>> Hello DJ,
>> A lot of people use LFS not only for i386 and AMD64. ARM and PPC comes to mind. Editing all targets is ideal. If LFS wants to go to /lib for AMD64, then review the CLFS pure64 bit patches for GCC, and our GLIBC instructions up to configure. We have used /lib ever since x86_64 and 2005. However, the way LFS is right now, when a user wants to include multilib, it isn't such a hassle. With using /lib, then the whole build needs redone, and not just a few changes after finishing LFS.
>> Review Martin Ward's notes about adding mulitlib after LFS is built at his github or home directory at the LFS server.
not me guv, haven't got a  git hub a/c!!! etc
>> Also, with AMD64, some targets will still install their libs into lib64. Example is e2fsprogs.
>> Also, with sysroot, there is a way to build all of LFS without the /tools link, too. There are some issues still to be ironed out, but Chris was working on it long ago. View the CLFS trac tickets for more info.
>> Sincerely,
>> William Harrington



More information about the lfs-dev mailing list