[gentoo-amd64] Re: Multilib or not?

[Duncan]

Tonko Mulder <tonko.mulder@×××××.com> posted
1227764120.6272.13.camel@Gaius, excerpted below, on  Thu, 27 Nov 2008
06:35:20 +0100:

> tonko@Gaius ~ $ ls -dl /lib /lib64
> drwxr-xr-x  4 root root   46 nov 26 21:32 /lib
> drwxr-xr-x 10 root root 8192 nov 27 06:08 /lib64

OK, that's the problem, I believe.  I too tried separate dirs, just to 
see how it would go, and had problems.

It seems a few packages, probably lvm2 among them, use /lib some of the 
time and /${LIBDIR} (which on amd64 equals /lib64) some of the time.  In 
particular, a couple packages I looked at (and lvm2 was probably one of 
them but I've forgotten by this point) would install to one but the 
initscripts would try to use the other.

Basically, they expect the usual Gentoo config which has a symlink one 
way or the other (it doesn't particularly matter which way, various 
Gentoo/amd64 stage releases have reversed each other).  If each one is 
its own dir, they fail, because they install to one and try to use the 
other, at least part of the time.

So, preferably from single-user-mode or elsewise when there's nothing 
that might crash due to their files temporarily moving out from under 
them, move everything from one into the other, then delete the empty one 
and create a symlink from it to the other.

As I said, which way you go shouldn't really matter.  To some extent, it 
depends on which one you think is the "proper" $LIBDIR in a 64-bit-only 
system.  If you think it's /lib because that's what you're used to using 
on 32-bit or simply because it's shorter to type, make /lib64 the symlink 
pointing at /lib.  If you (like me) like the 64 specified, even in the 
absence of any 32-bit, or if you want to stick closest to the LSB/FHS 
standard [1] for amd64/x86_64, you'll make /lib the symlink pointed at /
lib64.  In either case, if you ever decide you need to, you can always 
reverse yourself later.

Technically, those rcscript/addons/*.sh do indeed belong in /lib since 
they're shell scripts and as such are bitness independent [1, again].  
However, I expect what's happening is that the initscripts are using 
/${LIBDIR} for some of the calls, and on amd64 that's /lib64, so that's 
where the initscripts are trying to find them at least for those calls.  
As long as /lib and /lib64 ultimately resolve to the same place, it 
doesn't matter, but if they are both real directories, BAD THINGS (tm) 
happen.

---
[1] As I understand it, the FHS, File Hierarchy Standard, part of the 
LSB, is arguably inconsistent with itself in regard to $LIBDIR.  Non-
native-code such as scripts and bytecode compiled stuff (python/perl/
java), where every arch gets the same files, pretty consistently belongs 
in /lib and /usr/lib.  But there's an inconsistency with where 64-bit 
native-binary-code libraries go.  On ia64 (itanic/itanium), 64-bit really 
is seriously dominant and was intended to fully supplant 32-bit 
immediately.  It gets /lib.  32-bit is a distant also-ran that must be 
content with (IIRC) /lib32.

On amd64/x86_64, the considerations were much different.  Unlike ia64, 
amd64 is real hardware dual-bitness and it was apparent even before it 
came out (due to the flatlining of itanic, compared to predictions and 
hype, at least) that many/most people wanted to be able to run both 32-
bit and 64-bit code on the same system at the same time.  Due to the 
dominance of existing 32-bit code, it was far easier to let it take /lib 
so 32-bit packages wouldn't need any changes at all.  Since the process 
of making 64-bit packages already included porting the code, making sure 
it was 64-bit safe, etc, adding the comparatively trivial task of having 
it use /lib64 by default wasn't that big a deal, especially compared to 
being forced to update all those otherwise perfectly fine 32-bit packages 
to use something other than /lib.  So unlike ia64, amd64/x86_64 let 32-
bit have /lib and standardized on /lib64 for 64-bit code.  While this was 
designed to let 32-bit and 64-bit exist at least semi-happily
side-by-side, once the standard was established it made little sense to 
change it for 64-bit-only systems, so /lib64 it remains.

Of course then there's the whole (/usr)/libexec thing.  The idea there is 
that $LIBDIR (whether just lib or lib32/lib64) is for libraries and 
$BINDIR is for executables designed to be run directly, but where are 
executables really only designed to be called from other executables to 
be placed?  You don't want them in $BINDIR, since that's in $PATH and 
thus users will see it with tab-completion and the like, and these 
executables aren't designed to be run from the command line or otherwise 
(from a WM menu) directly invoked by the user.  Traditionally these went 
in lib as well, generally in package level subdirs thereof, but some 
people weren't happy with that and with the FHS standard, they decided 
libexec was a more suitable standard location.  So most systems now have 
a libexec, but this bit of the standard isn't so well known and many 
packages were already using lib by the time the standard came about and 
didn't want to hassle the change, so only a relatively few packages 
actually use libexec, despite what the standard says.  Also, I've never 
seen a root level /libexec, only /usr/libexec, so apparently it's only 
for binaries not needed during early boot, only after /usr is mounted.

That's the story as I understand it for x86, ia64, and amd64/x86_64.  I 
really have no idea how the other archs, ppc and sparc at least of which 
I know have both 32-bit and 64-bit variants, handle it, or what their FHS 
spec might be.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman