Re: Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf
On Wed, 2017-02-01 at 15:34:04 +0000, Steve McIntyre wrote:
> On Wed, Feb 01, 2017 at 05:08:50AM +0100, Guillem Jover wrote:
> >On Tue, 2017-01-31 at 22:44:36 +0000, James Cowgill wrote:
> >>
> >> Here libgsm.so has neither HARD or SOFT flags set. Also, asking gcc to
> >> generate a library which does not link against libc (this is used by
> >> sonames2elf in some packages) causes both flags to be set (maybe
> >> because it's compatible with both?).
> >
> >Even worse, I've found at least one instance of a package containing
> >binaries with EABIv4 (on armel, paris-traceroute). So I guess I'll have
> >to remove the flags matching on EM_ARM ELF binaries for now. At least
> >this will get us back to the previous behavior with objdump, no
> >regression in that sense.
> >
> >To be able to distinguish armel from armhf I'd probably need to check
> >the arm attributes section for Tag_ABI_VFP_args, which annoyingly
> >seems to be set even when the HARD flag is not set. :/ But this will
> >be for dpkg 1.19.x.
>
> Please don't go down that route, the ABI flags are intended to save
> people from that. I'm curious what's going wrong with libgsm1 here
> such that we're not seeing consistent ABI flags.
Well, I don't see any other sane option really. The problem is that
the code involved is in perl so must be arch independent, in contrast
to glibc, which is built against the architecture's ABI.
In this case dpkg-shlibdeps, sees an ELF object with an EM_ARM machine
ID which links against "stuff". And it traverses the linker paths, in
principle in the right order, but for example there is no guarantee of
the correct order when using the ld.so.conf paths, because they are
alpha sorted, not in host > foreign order. :(
So we have an ELF object that might or might not have the SOFT/HARD
flags set, which links against SONAMEs that when found might or might
not have the SOFT/HARD flags set. And it needs to know which one is
ABI compatible to keep it or discard it.
Also inferring the architecture from the package shipping the file is
not currently reliable, due to multilib, because those subvert the
packaging system by shipping .deb with contents for the wrong arch. :(
> If you're worried about EABIv4, does the logic of the dpkg checker not
> match the checks we added in glibc itself?
One of the problems is that currently the ABI matcher is a bit
simplistic, and it just combines various things that need to really
match and just compares the byte-streams for equality. Because that
allows the code to do good enough matching even when it does not know
new ELF machine types. It does better than the previous objdump
matcher in any case.
In the future I guess I'll need to special case some architectures,
in particular, at least ARM, MIPS and SH.
And just for reference the code being discussed is:
<https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/scripts/Dpkg/Shlibs/Objdump.pm#n173>
Thanks,
Guillem
Reply to: