-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Fri, 21 Oct 2011 14:20:13 -0500
Dennis Gilmore <den...@ausil.us> escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Fri, 21 Oct 2011 14:00:56 -0500
> Dennis Gilmore <den...@ausil.us> wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Sat, 17 Sep 2011 16:02:52 +0300
> > Panu Matilainen <pmati...@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@lists.rpm.org
> > > > http://lists.rpm.org/mailman/listinfo/rpm-maint
> > >
> > > _______________________________________________
> > > Rpm-maint mailing list
> > > Rpm-maint@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@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@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-----
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
