From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: RFC: multilib and the compatibility to singlelib
Date: Tue, 20 Oct 2009 16:25:15 +0000 (UTC) [thread overview]
Message-ID: <pan.2009.10.20.16.25.14@cox.net> (raw)
In-Reply-To: 4ADDD755.8050807@gentoo.org
Thomas Sachau posted on Tue, 20 Oct 2009 17:29:25 +0200 as excerpted:
> Michael Haubenwallner schrieb:
>> Isn't the intention of multilib to have a new (64bit) system be
>> compatible with the corresponding old (32bit) system?
>>
>> Please comment, thank you!
>> /haubi/
>
> If you have a 64bit system, the default should be 64bit, both for libs
> and for binaries. The additional multilib support allows to install and
> use additional 32bit libs and binaries. Since they are not the system
> dafault, they shouldnt be in some default place like lib, but instead a
> different, but clearly labeled dir like lib32. So the Gentoo way looks
> like the right way to me.
Except... it isn't, at least not if Gentoo is at all concerned about
standards, especially when they'll make things far easier for it.
What you just described was the logic applied with, for example, ia64,
which is true 64-bit (only) native. However (as I understand it), the
Linux FHS and LSB used somewhat different logic for x86_64.
See, x86_64 is hardware native dual-bitness, so both 32-bit and 64-bit
can be said to be true native hardware bitness (this is NOT the case with
ia64). Apparently due to that and to the vast number of legacy 32-bit
apps around, many binary-only apps doing obscure and unpredictable things
that could well break if assumptions about lib proved invalid, they
decided to keep the 32-bit lib location just as it was, believing it
easier to create the new lib64 for 64-bit, then to worry about whatever
obscure and exotic stuff various binary-only apps might be doing. Since
this was just one more change to add to the list of changes already being
made to port apps to amd64, it was considered easier than the other way,
and thus became the standard.
The problem was that Gentoo's early amd64 implementation predated this
standardization, and we had chosen the other way. While we've defaulted
to lib64 for 64-bit libs for years, it has never been considered anything
but experimental to break the lib --> lib64 link. AFAIK stable
baselayout still doesn't get its libdir usage consistent, putting files
in one but actually calling them using the other path, and boot breaks in
various frustrating ways if lib and lib64 are not the same directory.
Openrc gets it better now, but I'm not sure it's all fixed either -- it
certainly wasn't last time I tried breaking the link.
So before Gentoo can switch to the FHS/LSB 32-bit lib on amd64 multilib,
it must first fix those last inconsistent usages, and make it possible to
break the lib --> lib64 link. Then in theory at least, after awhile with
no bugs, or at least no big ones related to this issue, it might be
considered safe to move 32-bit back to lib, where the LSB/FHS says it
should be.
> And better support for this part is my current multilib-portage project,
> which allows compilation and installation of additional 32bit libs and
> binaries.
While I'm a no-multilib user here, I'm glad someone's finally getting
that close enough to mainline merge to talk about it! There's a lot of
folks for whom it will make life far easier. =:^)
--
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
next prev parent reply other threads:[~2009-10-20 16:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-20 13:06 [gentoo-dev] RFC: multilib and the compatibility to singlelib Michael Haubenwallner
2009-10-20 14:19 ` [gentoo-dev] " Nikos Chantziaras
2009-10-20 15:29 ` [gentoo-dev] " Thomas Sachau
2009-10-20 16:25 ` Duncan [this message]
2009-10-20 17:45 ` [gentoo-dev] " Mike Frysinger
2009-10-20 20:47 ` Jonathan Callen
2009-10-21 1:27 ` Mike Frysinger
2009-10-20 18:16 ` [gentoo-dev] " Mike Frysinger
2009-10-21 11:34 ` Michael Haubenwallner
2009-10-26 12:12 ` Mike Frysinger
2009-10-27 10:19 ` Michael Haubenwallner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2009.10.20.16.25.14@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox