27 Mar
2012
27 Mar
'12
18:55
Debian ARM arches:
- Debian 'armel', which defaults to ARMv4t (soft) maps to armv[4567]l
- 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.
Signed-off-by: Hector Oron <hector.oron(a)collabora.co.uk>
---
Build/Deb.pm | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Build/Deb.pm b/Build/Deb.pm
index b6c7cc6..3878fd4 100644
--- a/Build/Deb.pm
+++ b/Build/Deb.pm
@@ -26,6 +26,8 @@ sub parse {
$arch = 'i386' if $arch =~ /^i[456]86$/;
$arch = 'powerpc' if $arch eq 'ppc';
$arch = 'amd64' if $arch eq 'x86_64';
+ $arch = 'armel' if $arch =~ /^armv[4567]l$/;
+ $arch = 'armhf' if $arch eq 'armv7hl';
if (ref($fn) eq 'ARRAY') {
@control = @$fn;
--
1.7.9.1
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
27 Mar
27 Mar
20:32
Am Dienstag, 27. März 2012, 20:55:41 schrieb Hector Oron:
Debian ARM arches:
- Debian 'armel', which defaults to ARMv4t (soft) maps to armv[4567]l
- 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...
Signed-off-by: Hector Oron
<hector.oron(a)collabora.co.uk>
---
Build/Deb.pm | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Build/Deb.pm b/Build/Deb.pm
index b6c7cc6..3878fd4 100644
--- a/Build/Deb.pm
+++ b/Build/Deb.pm
@@ -26,6 +26,8 @@ sub parse {
$arch = 'i386' if $arch =~ /^i[456]86$/;
$arch = 'powerpc' if $arch eq 'ppc';
$arch = 'amd64' if $arch eq 'x86_64';
+ $arch = 'armel' if $arch =~ /^armv[4567]l$/;
+ $arch = 'armhf' if $arch eq 'armv7hl';
if (ref($fn) eq 'ARRAY') {
@control = @$fn;
--
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian(a)suse.de
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
20:43
Hello Adrian,
On 27/03/12 22:32, Adrian Schröter wrote:
Am Dienstag, 27. März 2012, 20:55:41 schrieb Hector
Oron:
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, armv[4567]l, maybe
armv[4567]el 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).
Debian ARM arches:
- Debian 'armel', which defaults to ARMv4t (soft) maps to armv[4567]l
- 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...
> Signed-off-by: Hector Oron
<hector.oron(a)collabora.co.uk>
> ---
> Build/Deb.pm | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/Build/Deb.pm b/Build/Deb.pm
> index b6c7cc6..3878fd4 100644
> --- a/Build/Deb.pm
> +++ b/Build/Deb.pm
> @@ -26,6 +26,8 @@ sub parse {
> $arch = 'i386' if $arch =~ /^i[456]86$/;
> $arch = 'powerpc' if $arch eq 'ppc';
> $arch = 'amd64' if $arch eq 'x86_64';
> + $arch = 'armel' if $arch =~ /^armv[4567]l$/;
> + $arch = 'armhf' if $arch eq 'armv7hl';
>
> if (ref($fn) eq 'ARRAY') {
> @control = @$fn;
>
--
Hector Oron
Collabora Ltd
Kett House, Station Road, Cambridge
CB1 2JH, United Kingdom
Telephone: +44 (0)1223 362967
Fax: +44 (0) 1223 351966
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
28 Mar
28 Mar
02:49
Am Dienstag, 27. März 2012, 22:43:35 schrieb Hector Oron:
--
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian(a)suse.de
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hello Adrian,
On 27/03/12 22:32, Adrian Schröter wrote:
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.
Am Dienstag, 27. März 2012, 20:55:41 schrieb
Hector Oron:
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, armv[4567]l, maybe
armv[4567]el 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). Debian ARM arches:
- Debian 'armel', which defaults to ARMv4t (soft) maps to armv[4567]l
- 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...
>
Signed-off-by: Hector Oron <hector.oron(a)collabora.co.uk>
> ---
> Build/Deb.pm | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/Build/Deb.pm b/Build/Deb.pm
> index b6c7cc6..3878fd4 100644
> --- a/Build/Deb.pm
> +++ b/Build/Deb.pm
> @@ -26,6 +26,8 @@ sub parse {
> $arch = 'i386' if $arch =~ /^i[456]86$/;
> $arch = 'powerpc' if $arch eq 'ppc';
> $arch = 'amd64' if $arch eq 'x86_64';
> + $arch = 'armel' if $arch =~ /^armv[4567]l$/;
> + $arch = 'armhf' if $arch eq 'armv7hl';
>
> if (ref($fn) eq 'ARRAY') {
> @control = @$fn;
>
07:20
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:
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
hardware)
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.
--
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian(a)suse.de
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Hello Adrian,
On 27/03/12 22:32, Adrian Schröter wrote:
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. Am Dienstag, 27. März 2012, 20:55:41 schrieb
Hector Oron:
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, armv[4567]l, maybe
armv[4567]el 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). Debian ARM arches:
- Debian 'armel', which defaults to ARMv4t (soft) maps to armv[4567]l
- 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...
11:05
Hello,
On 28/03/12 09:20, Adrian Schröter wrote:
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
hardware)
Depending on the hardware, but yes if CPU is ARMv7, it should be able to
run/handle hard, soft and softfp code in appropiate environments.
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.
Sounds nice and fine, but half-way. In Debian/Ubuntu distros, we name it
'multiarch' the capability to handle cross-arch dependencies, it mainly
attempts to tackle a couple problems: one, would be runtime problem,
where you get enough foreign architecture libraries installed to run
your application, either because hardware supports several ABI (i.e.
running 32-bit flash player on 64-bit machine); and second being able to
install enough libraries and headers for foreign arch and be able to use
a cross compiler to cross-build packages against those headers. It needs
some tweaks on the toolchain, packaging system, proper packages and FHS
changes. If you like to know more about it, please read
http://wiki.debian.org/Multiarch
Regards,
--
Hector Oron
Collabora Ltd
Kett House, Station Road, Cambridge
CB1 2JH, United Kingdom
Telephone: +44 (0)1223 362967
Fax: +44 (0) 1223 351966
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
15 Apr
15 Apr
09:58
New subject: [opensuse-arm] [opensuse-buildservice] [PATCH] [build] Map Debian ARM arches to OBS
On 28.03.2012, at 09:20, Adrian Schröter wrote:
Am Mittwoch, 28. März 2012, 04:49:01 schrieb Adrian
Schröter:
Could you please get in touch with the Fedora guys (maybe through the cross-distro ML?) on
that one? It'd be nice to get at least remotely compatible RPM semantics between RPM
based distros :).
Alex
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Am Dienstag, 27. März 2012, 22:43:35 schrieb
Hector Oron:
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
hardware)
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. Hello Adrian,
On 27/03/12 22:32, Adrian Schröter wrote:
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. Am Dienstag, 27. März 2012, 20:55:41 schrieb
Hector Oron:
> Debian ARM arches:
> - Debian 'armel', which defaults to ARMv4t (soft) maps to armv[4567]l
> - 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, armv[4567]l, maybe
armv[4567]el 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).
28 Mar
28 Mar
10:54
Hello Adrian,
On 28/03/12 04:49, Adrian Schröter wrote:
Am Dienstag, 27. März 2012, 22:43:35 schrieb Hector
Oron:
>>> Debian ARM arches:
>>> - Debian 'armel', which defaults to ARMv4t (soft) maps to
armv[4567]l
>>> - 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, armv[4567]l, maybe
> armv[4567]el 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.
Impossible unless your packaging system allows to install armv7l on
armv7hl environment under certain conditions and viceversa.
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 my case, imagine I have a build dependency foo [armel] | bar [armhf]
and I am using armv7l in OBS. If I am building against Ubuntu armel
distro, I would like the resolver to resolve foo [armel] instead of bar.
Also I thought armv7*h*l, *h* stands for hard, right?
In any case we have the problem now that we can not
detect the ABI from the architecture now...
Indeed, thats a problem.
We can take your patch now, but armhf will not be
selected right in our default settings.
Not sure why is that.
I would be happy, if anyone has a better proposal
here.
If I come up with better ideas, I'll resend a patch, as someone might
want to build optimized distro for R-PI (armv6 hard-float) and current
mapping would not allow for that.
>>> Signed-off-by: Hector Oron
<hector.oron(a)collabora.co.uk>
>>> ---
>>> Build/Deb.pm | 2 ++
>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/Build/Deb.pm b/Build/Deb.pm
>>> index b6c7cc6..3878fd4 100644
>>> --- a/Build/Deb.pm
>>> +++ b/Build/Deb.pm
>>> @@ -26,6 +26,8 @@ sub parse {
>>> $arch = 'i386' if $arch =~ /^i[456]86$/;
>>> $arch = 'powerpc' if $arch eq 'ppc';
>>> $arch = 'amd64' if $arch eq 'x86_64';
>>> + $arch = 'armel' if $arch =~ /^armv[4567]l$/;
>>> + $arch = 'armhf' if $arch eq 'armv7hl';
>>>
>>> if (ref($fn) eq 'ARRAY') {
>>> @control = @$fn;
--
Hector Oron
Collabora Ltd
Kett House, Station Road, Cambridge
CB1 2JH, United Kingdom
Telephone: +44 (0)1223 362967
Fax: +44 (0) 1223 351966
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
3519
days inactive
3538
days old
buildservice@lists.opensuse.org
7 comments
3 participants
participants (3)
-
Adrian Schröter -
Alexander Graf -
Hector Oron