Re: Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf
Hi,
On Thu, Feb 02, 2017 at 05:10:14AM +0100, Guillem Jover wrote:
>On Wed, 2017-02-01 at 15:34:04 +0000, Steve McIntyre wrote:
>>
>> 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.
Nod. I feel your pain... :-/
>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. :(
ACK. In the particular case of wine here, I can see that there's a
genuine problem that we've found (see other mail to Jens). What other
packages are showing problems?
>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.
Yup. By now, I'd hope that we should have a consistent set of flags in
programs and libraries, though. If there are any that are not yet
fixed, I'd like to know the details so we can fix them.
>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. :(
Ewww. :-(
>> 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>
ACK, I found that last night. It looks a little too simplistic, as you
say. It's not easy to get this right for all the arches, I totally
appreciate that!
--
Steve McIntyre, Cambridge, UK. steve@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss
Reply to: