Lennert Buytenhek wrote:
On Mon, Jan 14, 2008 at 12:44:06PM -0600, Mark Hatle wrote:
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.
E.g. if you try to compile gcc for a big-endian ARM system, the build
will certainly break if you pass it armv5teb_vfp-* or armv5eb_vfp-*
or something like that.
We don't pass the RPM arch into the configure. The configure is called
w/ simply armv5eb and armv5el.. (add t if thumb is enabled).
The ARCH references a set of macros, but does not actually define the
value. You just need to set the macro properly and not inherit the "RPM
Arch value".
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'.
That's generally how features are encoded on ARM, though. Like how
'ARMv5, Thumb, Extended DSP instructions' is encoded as 'armv5te' and
not as 'armv5_thumb_edsp'.
Right now, the rpm arch name for ARMv5TE little-endian is is
'armv5tel', and it would be kind of weird to have the Thumb and EDSP
capabilities encoded as single letters but to have VFP encoded as
_vfp in the same arch name.
My concern is simply that VFP encoding isn't defined in the ARM spec.
Either there has to be agreement among all of the (linux) arm community
or a new encoding shouldn't be created. ARM Ltd or someone else may
already have a defined use for that, so I believe conflicts are inevitable.
...
The problem with that would be that RPM package file names for VFP
and non-VFP packages would be identical.
Sure, but remember rpm package file names don't actually mean anything
other then the name of the file. :)
Just a suggestion.
--Mark
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
