[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Non-HF binaries in some Grip ARMHF debs

On Fri, 14 Jun 2013 16:34:27 +1000
Paul Whittaker <whitpa@velocitynet.com.au> wrote:

> FYI, I have encountered a few ARM EABI (i.e. ARMEL) binaries in packages 
> supposedly with architecture "armhf" in the 
> http://www.emdebian.org/grip/ repo.  For example:

Both armhf and armel are EABI (as opposed to old ABI which was ARMv4,
StrongARM for iPaq's et al.)

> I encountered several of these in a row when installing extra stuff on a 
> wheezy-grip ARMHF box, and thought at first that I must be doing 

There is a wheezy point release this weekend, as it happens, so there
is a window to fix these, however, my initial tests do not support your

The 'file' utility does not discriminate between armel and armhf
binaries (and therefore neither does lintian, yet). readelf does but
readelf does not agree with your analysis:

I unpacked deb-gview_0.2.10_armel.deb and deb-gview_0.2.10_armhf.deb

$ readelf -A armel/usr/bin/deb-gview | grep Tag_CPU
  Tag_CPU_name: "4T"
  Tag_CPU_arch: v4T

$ readelf -A armhf/usr/bin/deb-gview | grep Tag_CPU
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7

Both recent builds in unstable.

The equivalent packages from Grip:

deb-gview_0.2.10em1_armel.deb and deb-gview_0.2.10em1_armhf.deb

$ readelf -A grip-el/usr/bin/deb-gview |grep Tag_CPU
  Tag_CPU_name: "4T"
  Tag_CPU_arch: v4T

$ readelf -A grip-hf/usr/bin/deb-gview |grep Tag_CPU
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7

I then unpacked the fbset packages you described:

$ readelf -A 25/bin/fbset |grep Tag_CPU
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7

$ readelf -A 27/bin/fbset |grep Tag_CPU
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7

There is room for more investigation here, but my initial checks do not
support your conclusions.

> something wrong.  However, I was able to extract the debs on an ARMEL 
> platform and run select binaries from their contents, and they will 
> definitely not run under ARMHF, which is pretty conclusive.  I've had to 
> install non-gripped versions from standard ARMHF Wheezy as a workaround.

> Looks like someone used the wrong cross-compiler prefix when building 
> these, or something.  Can we get them fixed please?

Emdebian Grip packages are not cross-compiled - the compiled binaries
come unchanged from Debian.

It is possible that individual packages have been retained from the
time when armhf was only available via ports - that should have been
fixed when the packages became available from official mirrors but I
might have missed some.

However, I *must* have 100% reliable data before I can go hacking stuff
into the stable release.

It's not sufficient just to say "it didn't work on this box", I need to
have a programmatic method of checking individual packages in the
archive and if the output of readelf does not support detecting your
problem without false positives and without false negatives, then more
work needs to be done to isolate the precise issue.

Rather than checking the CPU, we could also check something related to
floating point:

$ readelf -A grip-hf/usr/bin/deb-gview |grep Tag_FP_arch
  Tag_FP_arch: VFPv3-D16

$ readelf -A 25/bin/fbset |grep Tag_FP_arch
  Tag_FP_arch: VFPv3-D16

$ readelf -A 27/bin/fbset |grep Tag_FP_arch
  Tag_FP_arch: VFPv3-D16

$ readelf -A grip-el/usr/bin/deb-gview |grep Tag_FP_arch

i.e. fbset_25 and fbset_27 are both declaring FP support when genuine
armel binaries do not.

That would indicate to me that fbset from 2.1-25em1_armhf.deb IS armhf,
as is fbset from 2.1-27em1_armhf. i.e. the binaries appear correct
when compared against known armel & armhf binaries.

One aim with this would be to file a wishlist bug against lintian to
ensure that it can use readelf reliably to determine that the correct
architecture is being packaged. It already has this test (I provided
the patch explicitly for Emdebian cross-building support) but it can be
enhanced to use another check as well as 'file' for exactly these
situations where file is insufficient.

As far as cross-compilation is concerned, lintian *will* catch any
cross-build failure because the 'file' output will be x86_64 or i386
*not* one of the ARM architectures. This is known to work and is still
seen frequently when the build system fails to pick up the
cross-compiler. It's easy to detect because any cross-compilation for
Emdebian happens on i386 or amd64 (for Emdebian toolchains, exclusively

I recommend that you undertake more investigation - I have no evidence
of a problem at the moment and I won't be changing any of the packages
until I can reliably determine the files affected.


$ sha256sum fbset_2.1-25em1_armhf.deb

$ sha256sum fbset_2.1-27em1_armhf.deb

$ sha256sum 25/bin/fbset 

$ sha256sum 27/bin/fbset 

$ sha256sum deb-gview_0.2.10_armel.deb 

$ sha256sum deb-gview_0.2.10em1_armel.deb 

$ sha256sum deb-gview_0.2.10em1_armhf.deb 

$ sha256sum deb-gview_0.2.10_armhf.deb 


Neil Williams

Attachment: pgpHBy8I5Nf5D.pgp
Description: PGP signature

Reply to: