[Rpm-maint] Re: [PATCH,RFC] arm: add support for VFP architectures

Mark Hatle mark.hatle at windriver.com
Tue Jan 15 14:38:33 UTC 2008

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.


More information about the Rpm-maint mailing list