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

Dennis Gilmore dennis at ausil.us
Fri Oct 21 19:20:13 UTC 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 21 Oct 2011 14:00:56 -0500
Dennis Gilmore <dennis at ausil.us> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sat, 17 Sep 2011 16:02:52 +0300
> Panu Matilainen <pmatilai at laiskiainen.org> wrote:
> 
> > On 09/16/2011 04:58 PM, Dennis Gilmore wrote:
> > > On Friday, September 16, 2011 04:46:33 AM Panu Matilainen wrote:
> > >> Oh I knew this would happen... the send-button is a magic
> > >> memory-enhancer in disguise. One (of probably many) forgotten
> > >> bits, this
> > >>
> > >> time hopefully with working address for Dennish too:
> > >>> On 09/15/2011 01:55 PM, Jon Masters wrote:
> > >>>> 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.
> > >>
> > >>    From what I've heard + read about the hardfp ABI, its not
> > >> actually possible to parallel-install with anything else because
> > >> even the dynamic linker has no clue whether hardfp or some other
> > >> ABI was used (see
> > >> http://wiki.debian.org/ArmHardFloatPort/VfpComparison, cheers to
> > >> our friends over Debian side again for a nice article :) Which
> > >> makes this a truly<cough>  "unique"<cough>  piece of work. I'd
> > >> love to know why it was done that way - my layman sense thinks
> > >> the compiler toolchain should be able to mark the ABI in the elf
> > >> headers (heck this is what the whole hwcap thing is about).
> > >> >
> > > _______________________________________________
> > > Rpm-maint mailing list
> > > Rpm-maint at lists.rpm.org
> > > http://lists.rpm.org/mailman/listinfo/rpm-maint
> > 
> > _______________________________________________
> > Rpm-maint mailing list
> > Rpm-maint at lists.rpm.org
> > http://lists.rpm.org/mailman/listinfo/rpm-maint
> > >
> > >> Since the ABI difference is apparently not recorded anywhere,
> > >> there's little chance of rpm being able to automatically do the
> > >> right thing really, and I dunno if its worth it trying to jump
> > >> through a whole lot of hoops for what seems an unachievable task.
> > >>
> > >> One simple brute-force "solution" that should work right now is
> > >> to just keep the softfp/hardfp "architectures" incompatible from
> > >> rpm POV and make the assumption that hardfp ABI will be used if
> > >> the system is capable of it. And if somebody wants to override
> > >> this assumption, that's what /etc/rpm/platform is for (allow
> > >> overriding rpm's hw detection).
> > >
> > > im not the biggest fan of this,  Maybe we can hard code it somehow
> > > at compilation time?
> > 
> > Care to elaborate why would you want to hardcode it instead of just 
> > utilizing an existing method for special-case override, which is
> > what we have here?
> > 
> > > as well as extend rpm-python to be able to expose it so yum
> > > can do the right thing.
> > 
> > The arch used by rpm (whether detected or overridden) is available
> > in %{_host_cpu} macro. If something else is needed then I need to
> > know what that would be.
> 
> its not sufficient. it evaluates to armv7l on a hardware floating
> point system. we would need it to be armv7hl or armv7hnl to give yum
> the info it needs

maybe _target_cpu could be used

though it would need a dict of compatiable arches

[dennis at panda02 ~]$ rpm --showrc |grep arm
build arch            : armv7hnl
compatible build archs: armv7hnl armv7hl noarch
install arch          : armv7hnl
compatible archs      : armv7hnl armv7hl noarch
optflags              : -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=neon -mthumb
	gpg --batch --no-verbose --no-armor --passphrase-fd 3 
- -14: __isa_name	armv7hnl
- -14: _arch	arm
- -14: _build_arch	arm
- -14: _host	armv7l-unknown-linux-gnueabi
- -14: _host_cpu	armv7l
- -11: _target	armv7hnl-linux
- -11= _target_cpu	armv7hnl
- -14: arm	armv3l armv4b armv4l armv4tl armv5tel armv5tejl armv6l armv7l armv7hl armv7nhl
- -11: optflags	-O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=neon -mthumb


[root at trimslice01 ~]#  rpm --showrc |grep arm
build arch            : armv7hl
compatible build archs: armv7hl noarch
install arch          : armv7hl
compatible archs      : armv7hl noarch
optflags              : -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb
	gpg --batch --no-verbose --no-armor --passphrase-fd 3 
- -14: __isa_name	armv7hl
- -14: _arch	arm
- -14: _build_arch	arm
- -14: _host	armv7l-unknown-linux-gnueabi
- -14: _host_cpu	armv7l
- -11: _target	armv7hl-linux
- -11= _target_cpu	armv7hl
- -14: arm	armv3l armv4b armv4l armv4tl armv5tel armv5tejl armv6l armv7l armv7hl armv7nhl
- -11: optflags	-O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb


the first output is a system that has a neon simd unit and the second
is without it. any software that can run on the second can also run on
the first. __isa_name really should be the same on both. 

long term maybe we can do something better. right now im looking for a
way to enable yum to detect the arches correctly without it resorting
to things like running readelf to determine the abi of the running
system.  since its noarch we cant just patch things in conditionally.

Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk6hxe0ACgkQkSxm47BaWfewcgCaA9dvKBEwk9tL58y39doakfjv
R/kAnjUqDBmsPER6fjnqcmO/B6cVCr+/
=cDQV
-----END PGP SIGNATURE-----


More information about the Rpm-maint mailing list