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.
Nod.
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 -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
