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

[Duncan]

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