lib lib32 lib64 in LFS 7 x86_64_multilib
ken at linuxfromscratch.org
Thu Oct 13 08:57:29 PDT 2005
On Thu, 13 Oct 2005, William Zhou wrote:
> 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.
das eine Mal als Tragödie, das andere Mal als Farce
More information about the lfs-dev