-----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