lib lib32 lib64 in LFS 7 x86_64_multilib

Ken Moffat ken at
Thu Oct 13 08:57:29 PDT 2005

On Thu, 13 Oct 2005, William Zhou wrote:

> Hi,
> I finished this build several days ago and started BLFS.

  You've pointed people at the "pure64" version, which _only_ installs 
64-bit : and for that, /lib is a walk in the park in BLFS (apart from 
packages which don't understand x86_64).

> However, the /lib is actually for lib32 instead of lib64.

  That's conventional multilib - other architectures came up with the "32 
and 64" option first, and for those it often makes sense to use /lib for 
most packages (because on RISC machines 64-bit binaries can be 
considerably bigger).  And therefore the various toolchain developers 
decided to support /lib for 32-bit and /lib64 for 64-bit.  On x86_64 the 
size difference is much less, and you get more registers to play with, 
so using 64-bit software is generally preferred.

> I believe the system tends to run in 64 bit. So all the
> libraries in BLFS have to go to /lib64.
> This is not as easy as it sounds. By specifying --libdir=/usr/lib64 solves
> majority of the problem. But there are still plenty of them
> which hardcodes the path into the program.
> To make this worse, library search is another problem because
> most of them searches /usr/lib and /lib. I don't want to sed
> all of them. It takes time.

  I haven't seen problems from the hardcoded library search path, but in 
general I agree with your comments.  If you haven't already done so, 
search the blfs-support archives for x86_64 - last time I had a working 
lib64 (albeit with a non-working 32-bit toolchain, from a not-wholly 
successful attempt to hack Ryan's buildscripts for new 
versions/methods), I posted comments on some of the packages I built. 
Since then, I think I also posted on some other stuff that needs 
adjustments for x86_64.

> Why does the book use /lib32+/lib(symlink to lib64) instead?

  Because there is still argument about the correct long-term way to do 
this.  The toolchain pretty-much supports lib+lib64, doing anything else 
has to be developed.  If/when I've managed to build a multilib system, 
I'll be able to test more BLFS packages and then start to look at 
lib+lib32 to see if I can achieve it, and if so, whether it actually 
helps (my main interest in 32-bit is for binary 32-bit plugins).

  But for the moment I'm stuckin conventional multilib at the temporary 
gcc (32-bit overwriting the 64-bit, no doubt I broke 
something in my scripts earlier).  So, for the moment, anybody who wants 
to install into /lib (64-bit) and /lib32 on x86_64 will have to try it 
for themselves.  I'm sure there will be a lot of interest (if only 
because it makes blfs so much easier), but playing with glibc and gcc 
has a very steep learning curve and is pretty much guaranteed to cause 
pain unless you already understand the toolchain in depth.

  das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-dev mailing list