Re: [gentoo-dev] Re: RFC: multilib and the compatibility to singlelib

[Mike Frysinger]

On Tuesday 20 October 2009 12:25:15 Duncan wrote:
> 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.

if you read FHS you'll see that both implementations are allowed.  Gentoo isnt 
violating anything here.  wrt LSB, who knows.  there are a ton of things we 
dont follow with LSB.

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

you can word "true native hardware bitness" (i dont even know what that means) 
however you like.  fact is, first ia64 gen had hardware support for x86.  no 
software levels needed.  we decided to not support ia64 multilib because (1) 
the hardware sucked so bad and (2) no one actually wanted it and (3) none of 
the mainline packages were/are doing it and (4) newer ia64 gens dropped 
support for it.

> 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 only binary encoded 32bit /lib/ path is the ldso which is why we symlinked 
that too

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

your "AFAIK" isnt useful.  there are no open bugs about either version and 
people assume that it's doing the right thing.

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

we've already switched to the FHS implementation
-mike