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.
> 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.
> 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.
> 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)...
> 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.
> 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.
> 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
> around.
>
>>
>> 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.
As you mentioned above... multiABI support is a combination of distribution and
package manager solutions. Right now I see RPM and a properly defined
distribution as the best solution out there. RPM can handle a policy based
conflict resolution, and the distro prevents conflicts "as much as possible".
--Mark
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
