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).
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).
Of course the entire hw-detection and arch-compatibility system is
seriously outdated and inadequate for todays needs, back in the nineties
systems were a lot less schizophrenic :) I've various vagueish ideas in
this area, but the current concept of "arch" is built so deep into tools
around rpm that fundamentally changing it is likely to be a long and
hard road.
- Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
