Jeremy Huntwork wrote: > Specifically, DIY currently has 64-bit libs in /lib64 and /usr/lib64 and > 32-bit libs in /lib, /usr/lib.
As does *every* normal distro I've seen that supports multilib...
(...)
> This way, both libraries are clearly identified and the default location
> of lib agrees with the default architecture gcc will build for. If
> people don't like the symlink, we can always remove {/usr,}/lib64 and
> just use {/usr,}/lib for 64-bit.
>
> The only thing is that (from what I can see) this will require
> configuring GCC to search in lib32 for 32 bit libs, which it doesn't do
> by default.
>
> Thoughts?
I can't speak for Ryan, but I have at least one thought. ;-)
ABI issues. Or at least, last time I remember seeing this idea on some
list or other (perhaps it was CLFS? perhaps DIY? can't remember for
sure), this was the reason for keeping /lib64 and /lib.
The dynamic linker *must* be /lib64/ld-linux-x86-64.so.2 for a 64-bit
executable, and *must* be /lib/ld-linux.so.2 for a 32-bit executable.
Otherwise binaries that weren't built on the system won't run. Symlinks
might let you work around this, but ... eeewww. Just set --libdir for
autoconf, or LIBDIR for other Makefiles.
(I have a fairly large collection of build64 scripts that hold what I've
done for various packages to get their libs into the right directory.
This is for LFS, chunks of BLFS, and several beyond-BLFS packages. The
*vast* majority needed nothing more than --libdir. If/when multilib
starts being worked on, I'd have no problem going through those and
seeing what packages in LFS needed what arguments. In fact, I might do
this anyway; now I'm curious...)
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
