[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
analysis.

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:

fbset_2.1-25em1_armhf.deb
$ readelf -A 25/bin/fbset |grep Tag_CPU
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7

fbset_2.1-27em1_armhf.deb
$ 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
amd64).

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.

Checksums:

$ sha256sum fbset_2.1-25em1_armhf.deb
d596c0ac1f505c45fb1491953155c115601e4a08d7dfcd2080474ddafe0adf70
fbset_2.1-25em1_armhf.deb

$ sha256sum fbset_2.1-27em1_armhf.deb
5051d76a3043bdd3d2e42f97def13f256152dcce3e7aeaa0669ef175f5f9c5ef
fbset_2.1-27em1_armhf.deb

$ sha256sum 25/bin/fbset 
65de96b9de7ddd5a9ba9a4a1bfce71d94727ddcdc453dddb5bf443f4ae435227
25/bin/fbset

$ sha256sum 27/bin/fbset 
111ec5928a521ac5c24fbf3d38d768fc3a088acfea4cdb38862c0be1e51d84ff
27/bin/fbset

$ sha256sum deb-gview_0.2.10_armel.deb 
009a779859d0b01887a30b7ea9cea4a7415a42d2a6063115cab59a2adea729e8
deb-gview_0.2.10_armel.deb

$ sha256sum deb-gview_0.2.10em1_armel.deb 
b2406ea4f52ab92013247ef8667bb87cbcb74f9010e894d4e0bf1f97ba69b032
deb-gview_0.2.10em1_armel.deb

$ sha256sum deb-gview_0.2.10em1_armhf.deb 
ce08cc91580b953580523a587556283bf07afa68d3b95ea922e6d3fa090c93c5
deb-gview_0.2.10em1_armhf.deb

$ sha256sum deb-gview_0.2.10_armhf.deb 
5ae88b416fd6562759b5222dc9f26382426832bc1f84829e83f69a4139d82169
deb-gview_0.2.10_armhf.deb


-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpQjYIl2NoRH.pgp
Description: PGP signature


Reply to: