[lfs-dev] Killing the /lib64 symlinks

DJ Lucas dj at linuxfromscratch.org
Sun Aug 7 13:11:26 PDT 2016

On August 7, 2016 2:29:29 PM CDT, William Harrington <kb0iic at berzerkula.org> 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
>> and arch? Realistically, we only need to modify 
>> gcc/config/i386/linux{,64}.h in LFS, and even then, only for GLIBC.
>> gcc/config/linux.h file is only for uclibc and bionic (Android), and 
>> musl (?) gets redefined in the arch specific target. Is there any
>> to continue to modify all of those files in LFS? The sed commands get
>> 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.

I'm sorry, I should have been more clear in my intention. LFS trunk only targets x86 and x86_64. Making changes to only the 4 necessary files, rather than all (as we do now), makes understanding what's happening (and more importantly, why) easier. Different goals in mind. Of course it makes sense for CLFS to patch all targets. Trunk uses sed instead of a patch in many places, presumably for some degree of educational value.

> 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

Exactly what I'm already working from. My initial build was using the pure64 patch that Chris posted (which included both pure64 GCC patches).

>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.

Yes, I've done it a few times in years past, when needed. I don't see much difference with or without the symlinks though. Still need to use /lib<qual> for the alternate arch. Fortunately, this will probably be one of those exercises I'll have to do myself to fully understand the interaction.

>Also, with AMD64, some targets will still install their libs into
>lib64. Example is e2fsprogs.

Interesting, I didn't see this on the initial build. /lib64 was empty, and /usr/lib64 didn't exist. Maybe I broke something and just didn't catch it, but it seemed reasonably sane which is why I continued. I didn't mess with it for more than a couple of hours before starting on book changes and rebuild.

>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

Was in the radar at one time, but has slipped long ago. Eventually. :-)



Sent from my Android device with K-9 Mail. Please excuse my brevity.

More information about the lfs-dev mailing list