lib lib32 lib64 in LFS 7 x86_64_multilib

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


On Thu, 13 Oct 2005, William Zhou wrote:

> http://www.linuxfromscratch.org/lfs/view/cross-lfs/x86_64-64/
>
> 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 libgcc_s.so 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.

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


More information about the lfs-dev mailing list