Adapting LFS SVN for multilib

[Bryan Kadzban]

Nathan Coulson wrote:
> BTW, one thought that I've been having in my setup, is using /usr/lib
> for 64bit, and /usr/lib/32 for 32bit [and  /usr/lib/32/bin for
> things like ncurses-config].

Interesting idea, but (as you note) it isn't standardized.  This means
your dynamic linker will not be in the standard location (...assuming
you do the same thing in /lib and /lib64, of course).  This, in turn,
means you're breaking the Linux standard x86 and x86_64 ABIs; they
require that the paths to the dynamic linkers be /lib/ld-linux.so.2 and
/lib64/ld-linux-x86-64.so.2, respectively.

In other words, 32-bit (and probably 64-bit) binaries that you didn't
compile will not run, without a good chunk of symlink hackery.  :-)

> I have this dream of a pure 64bit system, with 32bit 'not' being a
> integrated part of it.

32-bit in a chroot?  You'll still need /lib64 for the 64-bit linker, but
it may allow other stuff to be put into /lib (and/or symlink the two
directories), and likewise for under /usr.

> Disclaimer: Above paragraph is my own ideal, and in no way am I 
> suggesting that it should be the way forward.  Just thought it may 
> spark some thoughts into alternative setups.

Yeah, the problem with any alternative like that will be the ABI.
Existing binaries are already compiled to require the paths above;
anything that moves those files will break those binaries.

But as long as you're aware of the issue, feel free to do it on your own
setup...  :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://linuxfromscratch.org/pipermail/lfs-dev/attachments/20090112/f885314e/attachment.bin