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

Dennis Gilmore dennis at ausil.us
Wed Oct 26 21:00:45 UTC 2011


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

El Fri, 21 Oct 2011 14:20:13 -0500
Dennis Gilmore <dennis at ausil.us> escribió:
> -----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


ok since i have a ton of the oddball hardware here 

is there someway to get whats setting "compatible archs" in --showrc? 
i ask because

 rpm --showrc |grep armv7
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 -14: __isa_name	armv7hnl
- -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

rpm --showrc |grep sparc
build arch            : sparc64
compatible build archs: sparc64v sparc64 sparcv9v sparcv9 sparcv8 sparc
noarch install arch          : sparc64v
compatible archs      : sparc64v sparc64 sparcv9v sparcv9 sparcv8 sparc
noarch -14: _arch	sparc
- -14: _build_arch	sparc
- -14: _host	sparc-unknown-linux-gnu
- -14: _host_cpu	sparc
- -11: _target	sparc64-linux
- -11= _target_cpu	sparc64
- -11: optflags	%{__global_cflags} -m64 -mcpu=ultrasparc
- -14: sparc	sparc sparcv8 sparcv9 sparcv9v sparc64 sparc64v


_host_cpu and _target_cpu on sparc doesnt give me a way to work out
that im on a niagara box  but in both cases i could work out whats
needed by the info thats in "compatible archs" looking at rpmrc.c
RPM_MACHTABLE_INSTARCH is whats used internal. is that available at all?

on a niagara box 
In [2]: rpm.expandMacro('%{_target_cpu}')
Out[2]: 'sparc64'

on a trimslice running hardfp but without a neon simd
In [9]: rpm.expandMacro('%{_target_cpu}')
Out[9]: 'armv7hl'



Dennis


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

iEYEARECAAYFAk6odQIACgkQkSxm47BaWfdp6ACeIkJY5Gzawk34jTB/apGMvTmK
wEMAn3dAfZPb90rLCC6e9ZGc1pEtubmQ
=a4To
-----END PGP SIGNATURE-----


More information about the Rpm-maint mailing list