[Rpm-maint] Multiple ABI architectures (parallel installation, detection, handling)

Panu Matilainen pmatilai at laiskiainen.org
Sat Sep 17 11:19:54 UTC 2011

On 09/16/2011 10:40 PM, Mark Hatle wrote:
> On 9/16/11 4:02 AM, Panu Matilainen wrote:
>> On 09/15/2011 01:55 PM, Jon Masters wrote:
> ...
>>> What I want out of this discussion is a decision around how multiple
>>> ABIs within an architecture will be handled in general. If you're
>>> allergic to ARM, consider that in the Intel space there is now IA32,
>>> X32, and X64. The former is a 32-bit architecture, and the latter are
>>> both ABIs layered upon the 64-bit architecture. ARM and Intel aren't
>>> alone in this, there are others out there doing similarly fun things.
>> Rpm does have limited provisions for multilib/multiarch of course
>> (that's how x86_64 etc multilib archs work on Fedora/RHEL), but what's
>> there is not sufficient for generic multiarch/multiabi parallel support.
>> To outline the issues:
> Actually rpm already supports (and has a for a while) tri-arch/abi setups on
> MIPS.  MIPS64 already has o32, n32 and n64 support.  Generally speaking they're
> installed into /lib, /lib32 and /lib64 respectively.

Yes, this is what I was referring to as "limited provisions". Note I 
said for a *generic* multiarch setup, this just doesn't scale.

>> 1) Location of libraries and the like: the libraries for different ABI's
>> need to go to separate paths. Currently the non-debian world knows /lib
>> and /lib64, and while it's of course possible to add /libx32 and
>> whatnot, that gets *extremely* ugly real soon and simply does not scale
>> to things like cross-toolchains. The debian multiarch spec seems rather
>> nice in this regard: "simply" stuff it all into separate libraries in
>> $(prefix)/lib/$(arch)-$(abi) style distinct paths, without
>> differentiating between "native" and other archs/abis.
> As mentioned above, /lib, /lib32 and /lib64 are "known".  We intend to add
> /libx32 to our work in the near future.  It's already part of the embedded
> OE-Core work.

Nod, adding more /libxyz is probably the path of least immediate pain 
and works... as long as we're only talking about natively supported ABIs.

>> This is something that can't be decided and solved by rpm alone, the
>> entire distro and the compiler/linker toolchains are involved.
> Yes, the distro as a whole needs to agree on naming.  Not something that a
> packaging system can do.

BTW just to clarify this: whatever happens (or not) in rpm's 
multiarch/lib support, the current way of doing this has to be supported 
pretty much forever, and anything incompatible needs to be an opt-in 
"mode" that distros can choose if they so wish.

>> 2) Dependencies: there needs to be a way to distinguish between
>> (including but not limited to) libraries with identical soname-version
>> but different ABI. Rpm currently only knows of two kinds of soname
>> dependencies: ones with ()(64bit) postfix and ones without it. This
>> kinda works for what it gets used now, but is full of weird wrinkles
>> like some 64bit architectures not getting the (64bit) marker etc, and
>> obviously does not scale to full-fledged multi/cross-arch dependencies.
>> So the autogenerated soname dependencies would need to encode full
>> arch+abi(+maybesomethingelsetoo) into the dependencies. The problem here
>> is that changing the way dependencies are encoded is a MASSIVE
>> backwards-compatibility breakage, and probably would need both old-style
>> and new-style dependencies to be generated (although some of this might
>> be possible to arrange at runtime) for a transition period.
> On mips, we have a ()(32bit) as well..  So we end up with (o32) libfoo.so, (n32)
> libfoo.so()(32bit), (n64) libfoo.so()(64bit)...

Again, sure that works now (for a limited number of native ABIs) - it's 
the duct-tape path of least immediate pain.

>> For manually added dependencies %{_isa} goes a long way, but probably
>> not sufficient in its current form for a full-scale multiarch, multiabi
>> system.
> So far this has scaled well in our trials.  Soon to be adding in x32 may test
> this further.
> BTW "n32" is our default ABI for mips64 in our products.
>> Then there's the issue of dependency satisfiability across architectures
>> and abi's. Rpm has some provisions for this (dependency "colors"), but
>> its currently limited to just differentiate between 32bit vs 64bit (and
>> obviously "other") and there's no way to express allowed/prohibited
>> dependency matches across architectures.
> Actually there are three bits defined.. 32-bit, 64-bit and n32.

Ah, yes the "mips bit", I'd mostly forgotten about that. Its the same 
story with that - the color bits work for a limited number of native 
ABI's, but a bitfield does not scale beyond that. The "mips bit" should 
be renamed to something more general though :) If my "google search" 
source is right, n32 is has 32bit pointers but 64bit integers, whereas 
x32 has 32bit pointers and 32bit integers, so while we could probably 
just hijack the "mips bit" for x32, technically it should be different 
(in case some day somebody decides x32 doesn't cut it and adds an 
n32-like ABI for x86_64 ;)

>> The same coloring system is used to resolve elf-file conflicts on common
>> paths. This rather crazy system can be entirely avoided by better/more
>> fine-grained packaging: always place libraries and the like into
>> separate (sub)packages to eliminate conflict potential. Based on the
>> debian notes, dpkg apparently has issues with identical files shared
>> across multiple packages, but this is not an issue for rpm: it's
>> "always" been possible for multiple packages to share files, as long as
>> the files are identical.
> The conflict resolution works well, but it's much better to break the problem up
> so you don't need to use it much.  That is what we've tried to do for the most part.


>> 3) Package naming&  resolution: when in "multilib" mode (in rpm jargon,
>> "colored transaction"), packages with identical name but different
>> architecture can co-exist relatively peacefully. However the use of
>> "arch" alone is limiting from multiabi perspective, it'd require every
>> single different arch/abi combination to have arch of their own. Other
>> possibility is differentiating in the package name, but its klunky too.
>> I didn't (yet) see what debian is planning wrt this.
> I didn't think that was true.  I thought that the coloring system would allow
> you to use the same arch.  Maybe this isn't true in the rpm.org world, but it is
> in rpm5 and was last time I used the rpm.org version a few years ago.
> In the work I do, arch is treated as a hint for resolution, but he color is what
> is used for conflict resolution.

Yes the color is the only thing used for conflict resolution, the 
package naming mumble above was about something different really.

	- Panu -

More information about the Rpm-maint mailing list