Lennert Buytenhek wrote:
On Thu, Jan 03, 2008 at 11:01:46AM -0600, Mark Hatle wrote:
(please CC on replies, I'm not on rpm-maint@)
The attached patch adds a 'v' near the end of the machine name if
the (ARM) system we're running on supports VFP. This allows building
and using VFP-optimised RPM packages for ARM systems that have a VFP
floating point unit.
So e.g. glibc-2.7-2.armv5tel.rpm is the regular (softfloat) glibc that
we have now, and glibc-2.7-2.armv5tevl.rpm would then be a glibc built
to use VFP instructions, installable only on systems that have HWCAP_VFP.
As far as I was aware there wasn't a standard naming convention for VFP
in the arm cpu name.
Yeah, that's correct. It's not one of the feature letters.
So I'm a bit concerned that adding "...evl" (or ...evb) is going to
be confusing in the name.
What we have done is called it armv5el_vfp.
I've considered that, but that breaks configure scripts that match
against arm*b-* to determine whether the target is big-endian or not.
Using the 'v' is a bit of a hack, but I can't come up with anything
better.
We haven't found any configure scripts that change when VFP is enabled
or not. So as long as the compiler is doing the right thing and the RPM
macros are setup to properly list the gnu style arch, I think this is a
better answer. It's a lot more obvious as to what is being attempted
then embedding the 'v'.
(I would really like not to have to parse /proc/cpuinfo, but I don't
see how to get at _dl_hwcap or AT_HWCAP -- as far as I see, ld.so uses
this info to determine its library search path but doesn't export the
info.)
The HWCAP stuff in in the aux vector of course. I found a reference to
reading it from /proc/self/auxv, but I swear there is another way to
read this information w/o having to open any files.
I had a quick look at glibc, but I don't see any place where it makes
the info available. If you have this working, I'd be interested.
glibc does not export it directly. According to the glibc maintainers
the only proper way to do this is either w/ an additional argument to
main or reading the contents of /proc/self/auxv. The main arg way is
easier of course, but requires a more structural change.
Ideas?
An alternative suggestion. Instead of changing the name or the arch,
would it make sense to use HWCAP settings as a run-time dependency.
This would allow in-kernel VFP emulation (if there ever was a such a
thing implemented) to set the capability and run/install the code as
appropriate.
I don't understand that last sentence -- how does the approach I
proposed not allow having an in-kernel VFP emulator set HWCAP_VFP?
RPM could set an internal dependency (provide) when VFP is available.
The rpm packages that use VFP, could have an associated dependency
(require) for that item. It may not be as obvious because it's not in
the arch name.. but really all ARCH is, is a form of dependencies.
--Mark
_______________________________________________
fedora-arm mailing list
fedora-arm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-arm
