Re: Non-HF binaries in some Grip ARMHF debs

[Paul Whittaker <whitpa@velocitynet.com.au>]

On 14/06/2013 5:52 PM, Neil Williams wrote:
> 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:
> [snip]
>
> 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.

You are correct Neil, they are ARMHF binaries.  My apologies for jumping 
to conclusions.

However, there is something different about them that is preventing them 
from running on both wheezy-grip ARMHF and standard Wheezy ARMHF (both 
platforms that I tried).

It's the runtime linker name.  They're expecting /lib/ld-linux.so.3 
instead of /lib/ld-linux-armhf.so.3, and the wheezy / wheezy-grip libc6 
doesn't provide this as a backward compatibility symlink 
(understandably, as that would present a multi-arch problem).  I 
manually added one, and the binaries now run just fine.

So it looks like there is still an issue to resolve here - perhaps you 
can make use of your upcoming window.