[gentoo-dev] Re: multilib setup

[Duncan]

Mike Frysinger posted on Sun, 11 Sep 2011 15:55:49 -0400 as excerpted:

> all current multilib systems use the sub-profile
> features/multilib/lib32/.
>  in there, we set SYMLINK_LIB=yes.  this causes the 32bit libs to move
> from their normal ABI location in "lib" to "lib32" and then symlink
> "lib" to "lib64". this is the only currently supported setup, but can be
> considered legacy.

As a long-time Gentoo/amd64 user...

It's worth noting that Gentoo was quite out in front on the amd64 thing, 
and this present "legacy" setup was developed pretty much at the same 
time as the FHS spec that deals with the issue.  At the time, lib could 
have gone either way, legacy 32-bit lib with lib64, or new 64-bit lib 
with lib32.

The early amd64/Gentoo implementors apparently decided to follow ia64 and 
make lib64 the 64-bit location, but for transition reasons, made lib a 
symlink to it, with lib32 the 32-bit version.

Then the standard went the other way (apparently they decided the 64-bit 
target needed ported anyway so making it lib64 wasn't a big deal, and 
many 32-bit libraries and packages, with binary-only packages a major 
consideraction, would then simply continue to work without any changes at 
all).

For a couple years, Gentoo/amd64 actively planned to switch, with one of 
the first steps being implementation of portage's
FEATURES=multilib-strict, to catch the "bad" packages so bugs could be 
filed and they could be fixed.  I personally ran this feature for some 
years and reported several bugs based on it.

But somehow, it never happened, and over time, as 64-bit became common 
and pretty much everything (at least everything freedomware) was ported 
and the existing setup worked better and better, the pressure to leave 
what was now working reasonably well, well enough alone, grew.

Thus we arrive at the current situation.  I had actually thought that 
Gentoo/amd64 at least had given up on finally turning off that symlink 
and making lib 32-bit, and decided to leave things as they were and let 
time continue to deprecate 32-bit until it's no longer an issue, but 
Vapier's post indicates otherwise.  Still, it has been "in the future" 
since I switched to Gentoo/amd64 in 2004, and as I said, with the 
pressure for 32-bit gradually going away and the current situation 
established now for quite some time and working reasonably well, 
honestly, is it even worth the upset and bugs it'll cause, any more?

Meanwhile, I personally switched to no-multilib a few years ago now, and 
turned off FEATURES=multilib-strict after filing one last bug on it soon 
thereafter, so I don't know the current state there, but last I used it, 
the feature wasn't often killing merges, indicating that problem pretty 
much sinks into the ordinary bug count background.

Unfortunately, I and others have occasionally tried breaking the symlink 
and having separate lib and lib64 dirs, and even with FEATURES=multilib-
strict guaranteeing I had no breakers of that nature on the system, it 
still proved to be a rather difficult config to try to run, because 
there's apparently a lot of packages installing scripts, etc, to one 
path, but then trying to call them by the other path.  Actually, last I 
tried it, openrc was one of the problem packages so I couldn't even 
complete a normal boot!

Unfortunately, automated tinderbox testing for that isn't as easy as it 
might at first appear, since some packages will legitimately install both 
arch-neutral content to lib, and multilib content to lib64.  But not all 
those will be false-positives either, if they still install something to 
one but look for it in the other.  (AFAIK this was the problem with some 
of the openrc shell scripts, arguably arch-neutral and called from lib, 
but all installed (at least now) to (subdirs of) lib64.  But, last time I 
tried it was before the openrc stabilization push, IIRC, so it's quite 
possible things have changes since then.)

> in the future, multilib profiles we'll be moving to SYMLINK_LIB=no and
> using just features/multilib/.  so there will be no "lib32" dir at all,
> "lib" will be for 32bit libs (just like the matching 32bit arch), and
> "lib64" will be for 64bit libs.
>
> as for no-multilib systems, "lib64" will be the same, and "lib" will be
> symlinked to "lib64".  this will be easier i think to share files
> between multilib and non-multilib 64bit systems.

Thanks for that update, Mike.  That is likely to be the least problematic 
for no-multilib users, so I at least don't have to worry about it so 
much. =:^)

-- 
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