Sep 11, 2011, 4:10 PM
Post #2 of 6
(1974 views)
Permalink
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