Am Mittwoch, 28. März 2012, 04:49:01 schrieb Adrian Schröter:
> Am Dienstag, 27. März 2012, 22:43:35 schrieb Hector Oron:
> > Hello Adrian,
> > On 27/03/12 22:32, Adrian Schröter wrote:
> > > Am Dienstag, 27. März 2012, 20:55:41 schrieb Hector Oron:
> > >> Debian ARM arches:
> > >> - Debian 'armel', which defaults to ARMv4t (soft) maps to armvl
> > >> - Debian 'armhf', which defaults to ARMv7 (hard-float) maps to armv7hl
> > >>
> > >> Note Ubuntu 'armel' deprecated after 'precise' release, defaults to ARMv7
> > >> (softfp). So Ubuntu 'armel' should really map armv7l, but its out of scope
> > >> for this patch.
> > >
> > > Hm, doesnt it make sense to map armv7l and armv7hl to armhf ? AFAIK there are no
> > > arm cpus on v7 level without hardware fp.
> > >
> > > On the other hand this is about optimization level here and not hardware capabilities...
> > As I understand armv7hl is hard-float ABI, hence 'armhf'.
> > armv7l can be ARMv7/softfp as Ubuntu was doing on their ARM port
> > (armel), hence makes sense to me to map armv7l to 'armel'.
> > OTOH, Debian armel can run on any of those platforms, armvl, maybe
> > armvel should be added to the list. In other words, if I am
> > building armv7l debian packages I would expect them to use 'armel'
> > dependencies, while if I am building armv7hl, I would expect to build
> > against 'armhf' dependencies.
> > As a side note, I also see 'armv8el', I think that one comes from MeeGo,
> > and it should be deprecated and mapped in the future to aarch64 (64-bit
> > ARM architecture).
> That one is pure fantasy and will have nothing in common with real upcomming armv8, I think.
> But also architectures like armv7hl or armhf are fantasy when it comes to the linux
> kernel. They are just a hack in the packagemanagement to avoid to handle ABI compatibility
> on dependency level. But it makes for example impossible to install static binaries armv7l
> on armv7hl and vice versa. Even though it would run on real hardware.
> Or it would be thinkable to have also an entire set of packages with softfp on hardfp and vice
> versa. For that reason I selected just "armv7l" for our hardfp optimized distribution.
> But I agree that we seems to be special in the arm world with that way (so in worst case
> we need to switch to armv7hl as well and need to make armv7l and armv7hl as equivalent to avoid
> the describe problems) :/
> In any case we have the problem now that we can not detect the ABI from the architecture now...
> We can take your patch now, but armhf will not be selected right in our default settings.
> I would be happy, if anyone has a better proposal here.
Thinking again on the way to work about it, I think the following is the right approach:
1) Take your patch as is (done) ;)
2) Keep schedulers running on armv7l only, because we have just one pool of systems to build
for. The same machines can handle armv7 softfp and hardfp (is this right?, I am no expert in arm
For our openSUSE arm distro:
3) Define default _cpu_target as armv7hl, so we get also .armv7hl.rpm packages
4) Trim our rpm on arm to handle armv7l and armv7hl as equivalent.
5) extend library depend&provides handling with a "(hf)" extension to be able to distinguish
between hardfp and softfp packages on the same installation.
Note: The last point 5) would make our rpms incompatible with the ones from Fedora. But
it is IMHO the only way to handle mixed installations and the fedora way is IMHO
technical just wrong.
I would be happy to hear some more opinions on this.
SUSE Linux Products GmbH
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org