(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.
The idea behind this is that we want to support multiple different flavors of the Fedora/ARM port. Right now we have just an armv5tel softfloat flavor, but we'll probably end up with a VFP flavor soon, and later on perhaps also an ARMv6 flavor, maybe a pure Thumb2 flavor at some point, etc.
(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.)
Ideas?
Signed-off-by: Lennert Buytenhek buytenh@marvell.com
diff -up rpm-4.4.2.2/Makefile.am.orig rpm-4.4.2.2/Makefile.am --- rpm-4.4.2.2/Makefile.am.orig 2007-12-23 20:06:21.000000000 +0100 +++ rpm-4.4.2.2/Makefile.am 2007-12-23 20:06:41.000000000 +0100 @@ -159,8 +159,11 @@ install-data-local: $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv4l ;\ $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv4tl ;\ $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv5tel ;\ + $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv5tevl ;\ $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv5tejl ;\ - $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv6l ;;\ + $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv5tejvl ;\ + $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv6l ;\ + $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv6vl ;;\ sparc*) $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/sparc ;\ $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/sparcv8 ;\ $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/sparcv9 ;\ diff -up rpm-4.4.2.2/Makefile.in.orig rpm-4.4.2.2/Makefile.in --- rpm-4.4.2.2/Makefile.in.orig 2007-12-23 20:06:17.000000000 +0100 +++ rpm-4.4.2.2/Makefile.in 2007-12-23 20:06:31.000000000 +0100 @@ -1212,8 +1212,11 @@ install-data-local: $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv4l ;\ $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv4tl ;\ $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv5tel ;\ + $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv5tevl ;\ $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv5tejl ;\ - $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv6l ;;\ + $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv5tejvl ;\ + $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv6l ;\ + $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/armv6vl ;;\ sparc*) $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/sparc ;\ $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/sparcv8 ;\ $(mkinstalldirs) $(DESTDIR)$(pkgsrcdir)/RPMS/sparcv9 ;\ diff -up rpm-4.4.2.2/installplatform.orig rpm-4.4.2.2/installplatform --- rpm-4.4.2.2/installplatform.orig 2007-12-23 20:05:36.000000000 +0100 +++ rpm-4.4.2.2/installplatform 2007-12-23 20:06:05.000000000 +0100 @@ -32,7 +32,7 @@ target="`$RPM --eval '%{_target}'|sed -e case "$arch" in i[3456]86|pentium[34]|athlon) SUBSTS='s_i386_i386_ s_i386_i486_ s_i386_i586_ s_i386_i686_ s_i386_pentium3_ s_i386_pentium4_ s_i386_athlon_' ;; alpha*) SUBSTS='s_alpha_alpha_ s_alpha_alphaev5_ s_alpha_alphaev56_ s_alpha_alphapca56_ s_alpha_alphaev6_ s_alpha_alphaev67_' ;; - arm*) SUBSTS='s_arm_armv3l_ s_arm_armv4l_ s_arm_armv4tl_ s_arm_armv5tel_ s_arm_armv5tejl_ s_arm_armv6l_' ;; + arm*) SUBSTS='s_arm_armv3l_ s_arm_armv4l_ s_arm_armv4tl_ s_arm_armv5tel_ s_arm_armv5tevl_ s_arm_armv5tejl_ s_arm_armv5tejvl_ s_arm_armv6l_ s_arm_armv6vl_' ;; sparc*) SUBSTS='s_sparc(64|64v|v9v|v9)_sparc_ s_sparc64_sparcv9_;s_sparc([^v]|$)_sparcv9\1_ s_sparcv9_sparc64_;s_sparc([^6]|$)_sparc64\1_' ;; powerpc*|ppc*) SUBSTS='s_ppc64_ppc_ s_ppc([^6ip]|$)_ppc64\1_ s_ppc([^6ip]|$)_ppciseries_ s_ppc([^6ip]|$)_ppcpseries_ s_ppc([^6ip]|$)_ppc64iseries_ s_ppc([^6ip]|$)_ppc64pseries_' ;; s390*) SUBSTS='s_s390x_s390_ s_s390([^x]|$)_s390x\1_' ;; diff -up rpm-4.4.2.2/lib/rpmrc.c.orig rpm-4.4.2.2/lib/rpmrc.c --- rpm-4.4.2.2/lib/rpmrc.c.orig 2007-12-23 19:47:04.000000000 +0100 +++ rpm-4.4.2.2/lib/rpmrc.c 2007-12-23 20:18:59.000000000 +0100 @@ -1084,6 +1084,34 @@ static int is_pentium4()
#endif
+#if defined(__linux__) && defined(__arm__) && defined(__ARM_EABI__) +static int cpu_has_vfp(void) +{ + int has_vfp = 0; + FILE *fp; + + fp = fopen("/proc/cpuinfo", "r"); + if (fp != NULL) { + while (!feof(fp)) { + char linebuf[256]; + + if (fgets(linebuf, sizeof(linebuf), fp) == NULL) + break; + + if (memcmp(linebuf, "Features", 8) == 0) { + if (strstr(linebuf, " vfp") != NULL) + has_vfp = 1; + break; + } + } + + fclose(fp); + } + + return has_vfp; +} +#endif + #if defined(__linux__) && defined(__powerpc__) static jmp_buf mfspr_jmpbuf;
@@ -1293,6 +1321,18 @@ static void defaultMachine(/*@out@*/ con } # endif /* sparc*-linux */
+# if defined(__linux__) && defined(__arm__) && defined(__ARM_EABI__) + if (!memcmp(un.machine, "arm", 3)) { + int len = strlen(un.machine); + + if (len < sizeof(un.machine) - 1 && cpu_has_vfp()) { + un.machine[len + 1] = 0; + un.machine[len] = un.machine[len - 1]; + un.machine[len - 1] = 'v'; + } + } +# endif /* arm*-linux */ + # if defined(__GNUC__) && defined(__alpha__) { unsigned long amask, implver; diff -up rpm-4.4.2.2/macros.in.orig rpm-4.4.2.2/macros.in --- rpm-4.4.2.2/macros.in.orig 2007-12-23 20:05:14.000000000 +0100 +++ rpm-4.4.2.2/macros.in 2007-12-23 20:11:13.000000000 +0100 @@ -1192,7 +1192,8 @@ done \
#------------------------------------------------------------------------------ # arch macro for all supported ARM processors -%arm armv3l armv4b armv4l armv4tl armv5tel armv5tejl armv6l +%arm armv3l armv4b armv4l armv4tl armv5tel armv5tevl armv5tejl armv5tejvl armv6l armv6vl +%armvfp armv5tevl armv5tejvl armv6vl
#------------------------------------------------------------------------------ diff -up rpm-4.4.2.2/rpmrc.in.orig rpm-4.4.2.2/rpmrc.in --- rpm-4.4.2.2/rpmrc.in.orig 2007-12-23 19:57:11.000000000 +0100 +++ rpm-4.4.2.2/rpmrc.in 2007-12-23 20:05:00.000000000 +0100 @@ -65,8 +65,11 @@ optflags: armv4b -O2 -g -march=armv4 optflags: armv4l -O2 -g -march=armv4 optflags: armv4tl -O2 -g -march=armv4t optflags: armv5tel -O2 -g -march=armv5te +optflags: armv5tevl -O2 -g -march=armv5te -mfpu=vfp -mfloat-abi=softfp optflags: armv5tejl -O2 -g -march=armv5te +optflags: armv5tejvl -O2 -g -march=armv5te -mfpu=vfp -mfloat-abi=softfp optflags: armv6l -O2 -g -march=armv6 +optflags: armv6vl -O2 -g -march=armv6 -mfpu=vfp -mfloat-abi=softfp
optflags: atarist -O2 -g -fomit-frame-pointer optflags: atariste -O2 -g -fomit-frame-pointer @@ -133,8 +136,11 @@ arch_canon: armv3l: armv3l 12 arch_canon: armv4b: armv4b 12 arch_canon: armv4l: armv4l 12 arch_canon: armv5tel: armv5tel 12 +arch_canon: armv5tevl: armv5tevl 12 arch_canon: armv5tejl: armv5tejl 12 +arch_canon: armv5tejvl: armv5tejvl 12 arch_canon: armv6l: armv6l 12 +arch_canon: armv6vl: armv6vl 12
arch_canon: m68kmint: m68kmint 13 arch_canon: atarist: m68kmint 13 @@ -236,8 +242,11 @@ buildarchtranslate: armv4b: armv4b buildarchtranslate: armv4l: armv4l buildarchtranslate: armv4tl: armv4tl buildarchtranslate: armv5tel: armv5tel +buildarchtranslate: armv5tevl: armv5tevl buildarchtranslate: armv5tejl: armv5tejl +buildarchtranslate: armv5tejvl: armv5tejvl buildarchtranslate: armv6l: armv6l +buildarchtranslate: armv6vl: armv6vl
buildarchtranslate: atarist: m68kmint buildarchtranslate: atariste: m68kmint @@ -314,8 +323,13 @@ arch_compat: hppa1.0: parisc arch_compat: parisc: noarch
arch_compat: armv4b: noarch +arch_compat: armv6vl: armv6l +arch_compat: armv6vl: armv5tejvl arch_compat: armv6l: armv5tejl +arch_compat: armv5tejvl: armv5tejl +arch_compat: armv5tejvl: armv5tevl arch_compat: armv5tejl: armv5tel +arch_compat: armv5tevl: armv5tel arch_compat: armv5tel: armv4tl arch_compat: armv4tl: armv4l arch_compat: armv4l: armv3l @@ -412,8 +426,13 @@ buildarch_compat: mips: noarch buildarch_compat: mipsel: noarch
buildarch_compat: armv4b: noarch +buildarch_compat: armv6vl: armv6l +buildarch_compat: armv6vl: armv5tejvl buildarch_compat: armv6l: armv5tejl +buildarch_compat: armv5tejvl: armv5tejl +buildarch_compat: armv5tejvl: armv5tevl buildarch_compat: armv5tejl: armv5tel +buildarch_compat: armv5tevl: armv5tel buildarch_compat: armv5tel: armv4tl buildarch_compat: armv4tl: armv4l buildarch_compat: armv4l: armv3l
Lennert Buytenhek 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. 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.
The idea behind this is that we want to support multiple different flavors of the Fedora/ARM port. Right now we have just an armv5tel softfloat flavor, but we'll probably end up with a VFP flavor soon, and later on perhaps also an ARMv6 flavor, maybe a pure Thumb2 flavor at some point, etc.
Thumb2 at least has a naming convention so that should be easy to do.. (armv6t2el).
(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.
Another reference I found was using DL_FIND_ARG_COMPONENTS macro. But I don't really know anything about it. It's possible that the aux table might be optimized away.
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. RPM5 has a notion of run-time hardware capabilities and that is probably the way this is going to be implemented there. (They are close to release, so it won't be in the first version of RPM5.. but I do suspect the aux vector AT_HWCAP will be used on at least PPC in future version.)
--Mark
Signed-off-by: Lennert Buytenhek buytenh@marvell.com
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.
(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.
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?
RPM5 has a notion of run-time hardware capabilities and that is probably the way this is going to be implemented there. (They are close to release, so it won't be in the first version of RPM5.. but I do suspect the aux vector AT_HWCAP will be used on at least PPC in future version.)
My main interest is in Fedora, and I'd like the Fedora/ARM distro to stay as close to upstream Fedora as possible, so if this requires rpm5 (as it seems to), it won't work for me unless Fedora switches to rpm5 (which seems somewhat unlikely :-) or ports that feature over.
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
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.
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.
(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.
OK.
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.
The problem with that would be that RPM package file names for VFP and non-VFP packages would be identical.
On Mon, Jan 14, 2008 at 08:59:05PM +0100, Lennert Buytenhek wrote:
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.
[ replying to self ] On the other hand, VFP is not a core CPU feature (and doesn't get encoded in the arch name), so this is a bit of a non-argument.
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
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.
IMHO the same as you forbid installing PPC package on i386; you should forbid installing an ARM VFP package on an ARM system without VFP.
If you don't mark that package architecturally to be different than the soft-float version then mistakes are unavoidable.
This is where package dependencies come in. If the package depends on a hardware support for VFP, then the system needs to have a corresponding provide or it won't install.
(Of course people can use --nodeps.. but similarly they can use --ignorearch.)
In RPM 4.4.x ARCH implies certain hardware dependencies, but no explicit dependency exists. This was the reason for my suggestion.
--Mark
-----Original Message----- From: Rabeeh Khoury [mailto:rabeeh@marvell.com] Sent: Tue 1/15/2008 9:19 AM To: Hatle, Mark; Lennert Buytenhek Cc: rpm-maint@lists.rpm.org; fedora-arm@redhat.com Subject: RE: [PATCH,RFC] arm: add support for VFP architectures
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.
IMHO the same as you forbid installing PPC package on i386; you should forbid installing an ARM VFP package on an ARM system without VFP.
If you don't mark that package architecturally to be different than the soft-float version then mistakes are unavoidable.