Mailing List Archive

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

On Sunday, September 11, 2011 19:10:26 Duncan wrote:
> 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.

the reason for the slouching is simply man power/interest. the people
responsible for the amd64 port and multilib design moved on for various
reasons, and the multilib support pretty much stayed unchanged. of late, ive
been cleaning up and absorbing multilib responsibility as we support more ABIs
with our various non-amd64 targets. and with x32 coming, we need this stuff
to be in place ahead of time.
-mike

On Sun, Sep 11, 2011 at 03:55:49PM -0400, Mike Frysinger wrote:
> 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.

Isn't this slightly more complicated than it needs to be? Why not just
use /lib and no symlink for no-multilib 64-bit systems?

On Monday, September 12, 2011 15:19:29 Nathan Phillip Brink wrote:
> On Sun, Sep 11, 2011 at 03:55:49PM -0400, Mike Frysinger wrote:
> > 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.
>
> Isn't this slightly more complicated than it needs to be? Why not just
> use /lib and no symlink for no-multilib 64-bit systems?

all the 64bit binaries have /lib64/ld-linux-x86-64.so.2 encoded in them, so
/lib64/ must exist on the system.
-mike

On Mon, Sep 12, 2011 at 3:19 PM, Nathan Phillip Brink <binki@gentoo.org>wrote:

> On Sun, Sep 11, 2011 at 03:55:49PM -0400, Mike Frysinger wrote:
> > 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.
>
> Isn't this slightly more complicated than it needs to be? Why not just
> use /lib and no symlink for no-multilib 64-bit systems?
>

Well, the last sentence you quoted is the answer: "this will be easier i
think to share files between multilib and non-multilib 64bit systems."

Whether having to maintain separate binaries for multilib and non-multilib
amd64 systems is worth the tradeoff of having two lib directories is up for
debate I guess. I'm not sure how many people install precompiled 64-bit
binaries on their systems, but anybody who does maintain such a setup would
probably prefer not to have to build against libraries both in /lib64 and
/lib.

Rich