deb packages architecture problem.

deb packages architecture problem.

[Filip Zyzniewski]

Hi,

there is a problem with deb packages.

When installing packages on the target system dpkg complains:
"package architecture (arm) does not match system (armel)"

The question is - should we convince dpkg that the architecture is
arm, or build the packages so that their architecture is armel?

First solution may cause some problems with dpkg not expecting this
value on a particular system, the second means potential bugs
resulting from a deeper change in OpenEmbedded.

What do you think?

bye,
Filip Zyzniewski

Re: deb packages architecture problem.

[Andreas Oberritter]

On 02/17/2011 10:40 PM, Filip Zyzniewski wrote:
> there is a problem with deb packages.
> 
> When installing packages on the target system dpkg complains:
> "package architecture (arm) does not match system (armel)"
> 
> The question is - should we convince dpkg that the architecture is
> arm, or build the packages so that their architecture is armel?
> 
> First solution may cause some problems with dpkg not expecting this
> value on a particular system, the second means potential bugs
> resulting from a deeper change in OpenEmbedded.

Looking at package_deb.bbclass, the solution seems to be setting
DPKG_ARCH_arm ?= "armel" in there.

Regards,
Andreas

[PATCH] package_deb.bbclass: armel architecture name for eabi systems.

[Filip Zyzniewski]

For dpkg EABI system architecture is called armel, not arm.

Signed-off-by: Filip Zyzniewski <filip.zyzniewski@gmail.com>
---
 classes/package_deb.bbclass |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/classes/package_deb.bbclass b/classes/package_deb.bbclass
index 60e759d..87f31fa 100644
--- a/classes/package_deb.bbclass
+++ b/classes/package_deb.bbclass
@@ -15,6 +15,8 @@ DPKG_ARCH_i486 ?= "i386"
 DPKG_ARCH_i586 ?= "i386"
 DPKG_ARCH_i686 ?= "i386"
 DPKG_ARCH_pentium ?= "i386"
+DPKG_ARCH_linux-gnueabi ?= "armel"
+DPKG_ARCH_linux-uclibceabi ?= "armel"
 
 python package_deb_fn () {
     bb.data.setVar('PKGFN', bb.data.getVar('PKG',d), d)
-- 
1.7.1

Re: [PATCH] package_deb.bbclass: armel architecture name for eabi systems.

[Tom Rini]

On 02/18/2011 02:16 PM, Filip Zyzniewski wrote:
> For dpkg EABI system architecture is called armel, not arm.
>
> Signed-off-by: Filip Zyzniewski<filip.zyzniewski@gmail.com>
> ---
>   classes/package_deb.bbclass |    2 ++
>   1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/classes/package_deb.bbclass b/classes/package_deb.bbclass
> index 60e759d..87f31fa 100644
> --- a/classes/package_deb.bbclass
> +++ b/classes/package_deb.bbclass
> @@ -15,6 +15,8 @@ DPKG_ARCH_i486 ?= "i386"
>   DPKG_ARCH_i586 ?= "i386"
>   DPKG_ARCH_i686 ?= "i386"
>   DPKG_ARCH_pentium ?= "i386"
> +DPKG_ARCH_linux-gnueabi ?= "armel"
> +DPKG_ARCH_linux-uclibceabi ?= "armel"
>
>   python package_deb_fn () {
>       bb.data.setVar('PKGFN', bb.data.getVar('PKG',d), d)

I'm a little puzzled. So little endian gnueabi ARM is armel, little 
endian OABI ARM is arm.  What about big endian ARM cases?  Thanks!

-- 
Tom Rini
Mentor Graphics Corporation

Re: [PATCH] package_deb.bbclass: armel architecture name for eabi systems.

[Filip Zyzniewski]

On 2/18/11, Tom Rini <tom_rini@mentor.com> wrote:

> I'm a little puzzled. So little endian gnueabi ARM is armel, little
> endian OABI ARM is arm.  What about big endian ARM cases?  Thanks!

According to http://wiki.debian.org/ArmEabiPort:

==================
At the Extremadura emdebian meeting, 12-16 April 2006, the name
"armel" was chosen. If a bigendian arm EABI port will be created, it
will be called "armeb", and it will replace the previous oldabi-based
"armeb" port effort.
==================

bye,
Filip Zyzniewski

[PATCHv2] package_deb.bbclass/apt: armel architecture name for eabi systems.

[Filip Zyzniewski]

For dpkg EABI system architecture is called armel, not arm.
Reference: http://wiki.debian.org/ArmEabiPort

Signed-off-by: Filip Zyzniewski <filip.zyzniewski@gmail.com>
---
 classes/package_deb.bbclass |    2 ++
 recipes/apt/apt_0.7.20.2.bb |   13 ++++++++++++-
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/classes/package_deb.bbclass b/classes/package_deb.bbclass
index 60e759d..87f31fa 100644
--- a/classes/package_deb.bbclass
+++ b/classes/package_deb.bbclass
@@ -15,6 +15,8 @@ DPKG_ARCH_i486 ?= "i386"
 DPKG_ARCH_i586 ?= "i386"
 DPKG_ARCH_i686 ?= "i386"
 DPKG_ARCH_pentium ?= "i386"
+DPKG_ARCH_linux-gnueabi ?= "armel"
+DPKG_ARCH_linux-uclibceabi ?= "armel"
 
 python package_deb_fn () {
     bb.data.setVar('PKGFN', bb.data.getVar('PKG',d), d)
diff --git a/recipes/apt/apt_0.7.20.2.bb b/recipes/apt/apt_0.7.20.2.bb
index 5c932a5..c8a3516 100644
--- a/recipes/apt/apt_0.7.20.2.bb
+++ b/recipes/apt/apt_0.7.20.2.bb
@@ -7,12 +7,23 @@ SRC_URI += "file://no-doxygen.patch \
             file://no-ko-translation.patch \
             file://fix-gcc-4.4-compile.patch \
             file://use-host.patch "
-PR = "r3"
+PR = "r4"
 
 require apt-package.inc
 
 FILES_${PN} += "${bindir}/apt-key"
 
+do_configure_append_linux-gnueabi() {
+	sed -i \
+	's:^#define COMMON_ARCH "arm"$:#define COMMON_ARCH "armel":' \
+		${S}/include/config.h
+}
+
+do_configure_append_linux-uclibceabi() {
+	do_configure_append_linux-gnueabi()
+}
+
+
 do_stage() {
 	install -d ${STAGING_LIBDIR} ${STAGING_INCDIR}/apt-pkg
 	eval `cat environment.mak | grep ^GLIBC_VER | sed -e's, = ,=,'`
-- 
1.7.1

Re: [PATCHv2] package_deb.bbclass/apt: armel architecture name for eabi systems.

[Khem Raj]

On (20/02/11 00:30), Filip Zyzniewski wrote:
> For dpkg EABI system architecture is called armel, not arm.
> Reference: http://wiki.debian.org/ArmEabiPort
> 
> Signed-off-by: Filip Zyzniewski <filip.zyzniewski@gmail.com>
> ---
>  classes/package_deb.bbclass |    2 ++
>  recipes/apt/apt_0.7.20.2.bb |   13 ++++++++++++-
>  2 files changed, 14 insertions(+), 1 deletions(-)
> 
> diff --git a/classes/package_deb.bbclass b/classes/package_deb.bbclass
> index 60e759d..87f31fa 100644
> --- a/classes/package_deb.bbclass
> +++ b/classes/package_deb.bbclass
> @@ -15,6 +15,8 @@ DPKG_ARCH_i486 ?= "i386"
>  DPKG_ARCH_i586 ?= "i386"
>  DPKG_ARCH_i686 ?= "i386"
>  DPKG_ARCH_pentium ?= "i386"
> +DPKG_ARCH_linux-gnueabi ?= "armel"
> +DPKG_ARCH_linux-uclibceabi ?= "armel"

this seems ok 

>  
>  python package_deb_fn () {
>      bb.data.setVar('PKGFN', bb.data.getVar('PKG',d), d)
> diff --git a/recipes/apt/apt_0.7.20.2.bb b/recipes/apt/apt_0.7.20.2.bb
> index 5c932a5..c8a3516 100644
> --- a/recipes/apt/apt_0.7.20.2.bb
> +++ b/recipes/apt/apt_0.7.20.2.bb
> @@ -7,12 +7,23 @@ SRC_URI += "file://no-doxygen.patch \
>              file://no-ko-translation.patch \
>              file://fix-gcc-4.4-compile.patch \
>              file://use-host.patch "
> -PR = "r3"
> +PR = "r4"
>  
>  require apt-package.inc
>  
>  FILES_${PN} += "${bindir}/apt-key"
>  
> +do_configure_append_linux-gnueabi() {
> +	sed -i \
> +	's:^#define COMMON_ARCH "arm"$:#define COMMON_ARCH "armel":' \
> +		${S}/include/config.h
> +}
> +
> +do_configure_append_linux-uclibceabi() {
> +	do_configure_append_linux-gnueabi()
> +}
> +
> +

did you test the above calls ? I think these append should be defined
individually i.e. duplicate them

>  do_stage() {
>  	install -d ${STAGING_LIBDIR} ${STAGING_INCDIR}/apt-pkg
>  	eval `cat environment.mak | grep ^GLIBC_VER | sed -e's, = ,=,'`

while at it please get rid of do_stage
> -- 
> 1.7.1
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

-- 
-Khem

[PATCHv3] package_deb.bbclass/apt: armel architecture name for eabi systems.

[Filip Zyzniewski]

For dpkg EABI system architecture is called armel, not arm.
Reference: http://wiki.debian.org/ArmEabiPort

Signed-off-by: Filip Zyzniewski <filip.zyzniewski@gmail.com>
---
 classes/package_deb.bbclass |    2 ++
 recipes/apt/apt_0.7.20.2.bb |   21 ++++++++++++---------
 2 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/classes/package_deb.bbclass b/classes/package_deb.bbclass
index 60e759d..87f31fa 100644
--- a/classes/package_deb.bbclass
+++ b/classes/package_deb.bbclass
@@ -15,6 +15,8 @@ DPKG_ARCH_i486 ?= "i386"
 DPKG_ARCH_i586 ?= "i386"
 DPKG_ARCH_i686 ?= "i386"
 DPKG_ARCH_pentium ?= "i386"
+DPKG_ARCH_linux-gnueabi ?= "armel"
+DPKG_ARCH_linux-uclibceabi ?= "armel"
 
 python package_deb_fn () {
     bb.data.setVar('PKGFN', bb.data.getVar('PKG',d), d)
diff --git a/recipes/apt/apt_0.7.20.2.bb b/recipes/apt/apt_0.7.20.2.bb
index 5c932a5..e17d593 100644
--- a/recipes/apt/apt_0.7.20.2.bb
+++ b/recipes/apt/apt_0.7.20.2.bb
@@ -13,15 +13,18 @@ require apt-package.inc
 
 FILES_${PN} += "${bindir}/apt-key"
 
-do_stage() {
-	install -d ${STAGING_LIBDIR} ${STAGING_INCDIR}/apt-pkg
-	eval `cat environment.mak | grep ^GLIBC_VER | sed -e's, = ,=,'`
-	oe_libinstall -so -C bin libapt-pkg$GLIBC_VER-6 ${STAGING_LIBDIR}/
-	ln -sf libapt-pkg$GLIBC_VER-6.so ${STAGING_LIBDIR}/libapt-pkg.so
-	oe_libinstall -so -C bin libapt-inst$GLIBC_VER-6 ${STAGING_LIBDIR}/
-	ln -sf libapt-inst$GLIBC_VER-6.so ${STAGING_LIBDIR}/libapt-inst.so
-
-	install -m 0644 include/apt-pkg/*.h ${STAGING_INCDIR}/apt-pkg/
+fix_eabi_architecture() {
+	sed -i \
+	's:^#define COMMON_ARCH "arm"$:#define COMMON_ARCH "armel":' \
+		${S}/include/config.h
+}
+
+do_configure_append_linux-gnueabi() {
+	fix_eabi_architecture
+}
+
+do_configure_append_linux-uclibceabi() {
+	fix_eabi_architecture
 }
 
 SRC_URI[md5sum] = "e6ee1b594f6ed5fab5cb593ee46cfc21"
-- 
1.7.1

Re: [PATCHv2] package_deb.bbclass/apt: armel architecture name for eabi systems.

[Filip Zyzniewski]

On 2/20/11, Khem Raj <raj.khem@gmail.com> wrote:

> did you test the above calls ? I think these append should be defined
> individually i.e. duplicate them

I've changed it to be symmetrical (both call a separate function) so
that I can verify it on my build and avoid duplication of code.

> while at it please get rid of do_stage

I've removed it and resulting package has the same contents, so removed it is.

I have just realised that I've skipped increasing PR, I'll send a
fixed one in a minute.

bye,
Filip Zyzniewski

[PATCHv4] package_deb.bbclass/apt: armel architecture name for eabi systems.

[Filip Zyzniewski]

For dpkg EABI system architecture is called armel, not arm.
Reference: http://wiki.debian.org/ArmEabiPort

Signed-off-by: Filip Zyzniewski <filip.zyzniewski@gmail.com>
---
 classes/package_deb.bbclass |    2 ++
 recipes/apt/apt_0.7.20.2.bb |   21 ++++++++++++---------
 2 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/classes/package_deb.bbclass b/classes/package_deb.bbclass
index 60e759d..87f31fa 100644
--- a/classes/package_deb.bbclass
+++ b/classes/package_deb.bbclass
@@ -15,6 +15,8 @@ DPKG_ARCH_i486 ?= "i386"
 DPKG_ARCH_i586 ?= "i386"
 DPKG_ARCH_i686 ?= "i386"
 DPKG_ARCH_pentium ?= "i386"
+DPKG_ARCH_linux-gnueabi ?= "armel"
+DPKG_ARCH_linux-uclibceabi ?= "armel"
 
 python package_deb_fn () {
     bb.data.setVar('PKGFN', bb.data.getVar('PKG',d), d)
diff --git a/recipes/apt/apt_0.7.20.2.bb b/recipes/apt/apt_0.7.20.2.bb
index 5c932a5..ca0787c 100644
--- a/recipes/apt/apt_0.7.20.2.bb
+++ b/recipes/apt/apt_0.7.20.2.bb
@@ -7,21 +7,24 @@ SRC_URI += "file://no-doxygen.patch \
             file://no-ko-translation.patch \
             file://fix-gcc-4.4-compile.patch \
             file://use-host.patch "
-PR = "r3"
+PR = "r4"
 
 require apt-package.inc
 
 FILES_${PN} += "${bindir}/apt-key"
 
-do_stage() {
-	install -d ${STAGING_LIBDIR} ${STAGING_INCDIR}/apt-pkg
-	eval `cat environment.mak | grep ^GLIBC_VER | sed -e's, = ,=,'`
-	oe_libinstall -so -C bin libapt-pkg$GLIBC_VER-6 ${STAGING_LIBDIR}/
-	ln -sf libapt-pkg$GLIBC_VER-6.so ${STAGING_LIBDIR}/libapt-pkg.so
-	oe_libinstall -so -C bin libapt-inst$GLIBC_VER-6 ${STAGING_LIBDIR}/
-	ln -sf libapt-inst$GLIBC_VER-6.so ${STAGING_LIBDIR}/libapt-inst.so
+fix_eabi_architecture() {
+	sed -i \
+	's:^#define COMMON_ARCH "arm"$:#define COMMON_ARCH "armel":' \
+		${S}/include/config.h
+}
+
+do_configure_append_linux-gnueabi() {
+	fix_eabi_architecture
+}
 
-	install -m 0644 include/apt-pkg/*.h ${STAGING_INCDIR}/apt-pkg/
+do_configure_append_linux-uclibceabi() {
+	fix_eabi_architecture
 }
 
 SRC_URI[md5sum] = "e6ee1b594f6ed5fab5cb593ee46cfc21"
-- 
1.7.1

Re: [PATCH] package_deb.bbclass: armel architecture name for eabi systems.

[Phil Blundell]

On Fri, 2011-02-18 at 14:50 -0700, Tom Rini wrote:
> I'm a little puzzled. So little endian gnueabi ARM is armel, little 
> endian OABI ARM is arm.  What about big endian ARM cases?  Thanks!

Debian has never had big-endian ARM as an officially supported
architecture, so to that extent there's no precedent to follow in this
area.  

The natural name for a big-endian gnueabi port would obviously be
"armeb".  That does leave big-endian OABI somewhat out in the cold but,
given that OABI has been obsolescent for the best part of a decade, this
doesn't seem totally unreasonable.  If anybody did want to use dpkg with
such a thing (and wanted to avoid colliding with armeb) then I guess
they'd have to name it "armob" or something.

p.

Re: [PATCH] package_deb.bbclass: armel architecture name for eabi systems.

[Leon Woestenberg]

Hello,

On Mon, Feb 21, 2011 at 4:12 PM, Phil Blundell <philb@gnu.org> wrote:
> On Fri, 2011-02-18 at 14:50 -0700, Tom Rini wrote:
>> I'm a little puzzled. So little endian gnueabi ARM is armel, little
>> endian OABI ARM is arm.  What about big endian ARM cases?  Thanks!
>
> Debian has never had big-endian ARM as an officially supported
> architecture, so to that extent there's no precedent to follow in this
> area.
>
> The natural name for a big-endian gnueabi port would obviously be
> "armeb".  That does leave big-endian OABI somewhat out in the cold but,
> given that OABI has been obsolescent for the best part of a decade, this
> doesn't seem totally unreasonable.  If anybody did want to use dpkg with
> such a thing (and wanted to avoid colliding with armeb) then I guess
> they'd have to name it "armob" or something.
>

adding some history here:

<quoting Lennert Buytenhek>

> It's not so unusual anymore since intel introduced the IXP series
> of chips which come with mostly BE oriented reference designs.

The nslu2 itself comes with an ixp4xx CPU, but the armeb port is also
used on a number of ixp2000 boards. Having a big-endian arm distro to
run on the ixp2000 was an important reason for developing this port.

As to why I chose armeb instead of armbe, partially because of the
-EB/-EL thing, partially because the arch name also has the endianity
at the end (armv4b, armv4l, armv5teb, armv5tel), partially because when
I first started porting a distro to armeb, a number of tools (binutils?
I can't remember now.) did accept arm*b-*-* as target string but didn't
accept armbe-*-*.

The latter might have changed in the meanwhile, but the original
decision to use armeb instead of armbe was made over two years ago.

cheers,
Lennert
</quoting Lennert Buytenhek>


Please note that there have been lots of issues with armbe (in
configure scripts etc), so I would recommend using armeb.


Regards,
-- 
Leon

Re: [PATCH] package_deb.bbclass: armel architecture name for eabi systems.

[Khem Raj]

On (21/02/11 16:41), Leon Woestenberg wrote:
> Hello,
> 
> On Mon, Feb 21, 2011 at 4:12 PM, Phil Blundell <philb@gnu.org> wrote:
> > On Fri, 2011-02-18 at 14:50 -0700, Tom Rini wrote:
> >> I'm a little puzzled. So little endian gnueabi ARM is armel, little
> >> endian OABI ARM is arm.  What about big endian ARM cases?  Thanks!
> >
> > Debian has never had big-endian ARM as an officially supported
> > architecture, so to that extent there's no precedent to follow in this
> > area.
> >
> > The natural name for a big-endian gnueabi port would obviously be
> > "armeb".  That does leave big-endian OABI somewhat out in the cold but,
> > given that OABI has been obsolescent for the best part of a decade, this
> > doesn't seem totally unreasonable.  If anybody did want to use dpkg with
> > such a thing (and wanted to avoid colliding with armeb) then I guess
> > they'd have to name it "armob" or something.
> >
> 
> adding some history here:
> 
> <quoting Lennert Buytenhek>
> 
> > It's not so unusual anymore since intel introduced the IXP series
> > of chips which come with mostly BE oriented reference designs.
> 
> The nslu2 itself comes with an ixp4xx CPU, but the armeb port is also
> used on a number of ixp2000 boards. Having a big-endian arm distro to
> run on the ixp2000 was an important reason for developing this port.
> 
> As to why I chose armeb instead of armbe, partially because of the
> -EB/-EL thing, partially because the arch name also has the endianity
> at the end (armv4b, armv4l, armv5teb, armv5tel), partially because when
> I first started porting a distro to armeb, a number of tools (binutils?
> I can't remember now.) did accept arm*b-*-* as target string but didn't
> accept armbe-*-*.
> 
> The latter might have changed in the meanwhile, but the original
> decision to use armeb instead of armbe was made over two years ago.
> 
> cheers,
> Lennert
> </quoting Lennert Buytenhek>
> 
> 
> Please note that there have been lots of issues with armbe (in
> configure scripts etc), so I would recommend using armeb.

In OE we have EABI as default on ARM and boards from armv4+ therefore
oabi is less of an issue moving forwards. We should be fine using
armeb for BE ARM EABI only as I dont expect any oabi port for armeb in
future

-Khem