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

Dennis Gilmore dennis at ausil.us
Fri Nov 4 00:37:13 UTC 2011


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

El Thu, 03 Nov 2011 14:26:58 +0200
Panu Matilainen <pmatilai at laiskiainen.org> escribió:
> On 10/27/2011 12:00 AM, Dennis Gilmore wrote:
> [...big snip...]
> >>> 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'
> 
> Yup, my bad - neither macro ends up containing the "install arch" in
> the end. The target gets set for "install arch" during initialization
> (to read the correct platform file) but is then reset in the bowels
> of rpmrc.
> 
> The arch (compat and other) tables aren't really exported anywhere at 
> all. In python the only thing is rpm.archscore() which returns
> non-zero values for arch strings that are compatible with the system
> architecture according to rpm's internal knowledge (configuration &
> detected stuff). But then yum doesn't use even that, it does its own
> hardware detection by reading /proc/cpuinfo and all (see
> rpmUtils/arch.py) and uses its own hardcoded compatibility tables.
> 
> Maybe rpm should export more of selected bits of its internal hw
> info. But even if it did, yum is unlikely to rely on that info being
> available anytime soon. So you'll end up (re)writing the ARM
> detection in yum anyway, might as well just add it there now and move
> on to other issues 
> - reworking the entire way yum vs rpm arch detection is just not
> going to happen in the current stable releases (talking of the
> rpm/yum versions included in F15-16 and probably F17 too)

the patch i have for rpm is really a hack and not complete, it needs to
be conditionally applied. to do all the arch detection in yum  would
mean adding deps to yum on elfutils and is pretty ugly and invasive. i
think i can make it work using %{_target_cpu} but its only going to
work in this one use case but i guess so be it.  It really is an issue
that needs to be solved correctly and needs some discission and a place
on the roadmap.

yes its hard, yes its not fun. but it needs doing

we have the recently announced armv8 arch that is 64 bit and means we
need to work out how to support that as well. likely we can do the
x86/x86_64 way with armhfp and arm64

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

iEYEARECAAYFAk6zM70ACgkQkSxm47BaWfcuBQCeNV2dmcgyTMWZ/j3OzKIQA+go
mrIAoMK9JkkwwcMf6kgB2OfrBKcZ/BuN
=PwZX
-----END PGP SIGNATURE-----


More information about the Rpm-maint mailing list