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

Panu Matilainen pmatilai at redhat.com
Fri Sep 16 09:02:23 UTC 2011

On 09/15/2011 01:55 PM, Jon Masters wrote:
> Folks,
> I've taken the liberty of inviting myself to the party :) I'm also on
> IRC on Freenode, and have been following RPM development for some time
> in a lurking capacity. A number of you know me from the office, but
> greetings to everyone else!

Thanks for taking the time to write this, hmm, initiative. I'm not going 
to pretend I have solutions at hand (I dont), so this will be just 
random initial thoughts on the subject(s) which hopefully will inspire 
further ideas & discussion.

> We're currently engaged in bootstrapping support for "hardfp"[0] in the
> Fedora Linux distribution (specifically, in release 15 thereof) for use
> by systems featuring an ARM version 7 A (Application) processor or later
> ARM. This is a new ABI as far as Linux is concerned, and it is parallel
> installable with the older "EABI" or (loosely) "softfp" that has been
> supported up until this point (for example in our ARM version 5 port, as
> released in Fedora 13).
> Currently, we have a hacked up RPM binary that introduces e.g.:
> * armv7hl
> * armv7nhl (MeeGo disagrees on this and calls it "hnl" btw)
> * armv7thl [1]

I dont really have an opinion of what the umphteen ARM (and other) 
architectures should call themselves. However since there is a 
pre-existing naming practise in Meego, I'd like to see that used unless 
there are strong arguments against it. In fact the Meego folks did 
contact me on the arch naming before going on with their selection (and 
I didn't have any more opinion about it than I do now), its just that I 
don't recall ever receiving the patch to add them, so it went 
"unreserved" from upstream POV.

> Dennis has some code (he can forward) that is carried in F15 currently,
> and which Panu has previously taken a look at. It uses the typical
> parsing of /proc as an approach, though we agree that the "correct" way
> to do that would be through AT_HWCAPS, as in here:
> https://wiki.linaro.org/Resources/HowTo/DeterminingCPUFeatures
> (last raised on rpm-maint@ in 2008 as it turns out :) )

I've been poking around AT_HWCAP and friends for the last couple of 
days, inspired by private emails around this topic. It would seem that 
AT_PLATFORM + AT_HWCAP could be used to (easily even) replace the 
current hodge-podge of inline assembly magic & parsing the rather ad-hoc 
arch-dependent formatted /proc/cpuinfo for arch + capability detection. 
The contents of AT_* vectors are highly arch-specific, but at least the 
interface to access that data is the same across architectures. And this 
mechanism does exist on at least some other OS'es than just Linux, 
making it a whole lot more "portable" than the current methods. (whether 
anybody really actually cares about rpm on non-Linux platforms is 
another question)

So far it looks like a promising path, but this is mostly just an 
implementation detail and not that big a deal in itself.

> All of the existing stuff assumes that if we have vfpv3 on ARMv7 we're
> going to be running in hardfp. We can keep that notion around in the
> very short term, but we need a longer term solution. And although we
> don't necessarily plan actual parallel installs of different ABIs, it is
> not technically the case that all ARMv7 systems are going to be running
> the hardfp port. We may e.g. install an ARMv5 port therein.
> Add to this the fact that we now have X32 (a new x86 32-bit ABI) in the
> Intel world, and it's clear that RPM needs a generic way to handle
> multiple possible ABIs within the same architecture. I personally favor
> the "multiarch" approach being taken by Debian, but I don't really want
> to espouse one particular approach here. What I do want to do is to kick
> off a discussion thread in which you RPM folks can decide how you want
> to handle multiple ABIs in both the ARM and non-ARM worlds that myself,
> Dennis, and others occupy. I'm sure Dennis, Panu, and others can point
> folks at existing patches.

...but *this* is a vast topic reaching far beyond rpm. Our Debian 
friends have done a whole lot of studying (and without doubt, a whole 
lot of arguing :) and documenting the issue. Regardless of what rpm ends 
up in rpm, the Debian multiarch docs are well worth reading:
http://wiki.debian.org/Multiarch/TheCaseForMultiarch (more info + links 
at http://wiki.debian.org/Multiarch)

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

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.

This is something that can't be decided and solved by rpm alone, the 
entire distro and the compiler/linker toolchains are involved.

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.

For manually added dependencies %{_isa} goes a long way, but probably 
not sufficient in its current form for a full-scale multiarch, multiabi 

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.

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.

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.

4...) Probably loads of other things that I've overlooked and/or can't 
remember right now. But rather than try to write an all-encompassing 
answer that eventually dies of old age unsent in my drafts folder (bad 
habit of mine), I'm hitting send with this now to have something to kick 

> Thanks for your time. I'm attaching Dennis' original patch. Just so you
> can see what it does, not so that you can directly consider that as the
> solution that will be necessarily eventually in upstream if you can
> figure out a preferred means to generically handle multiABI.

FWIW, I'm going to have a stab at converting the existing arch-detection 
(on linux) to use the auxiliary vector AT_* data. If that goes in, doing 
the same for ARM should be a no-brainer (and well, can be of course be 
done regardless of what other archs do)

	- Panu -

More information about the Rpm-maint mailing list