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. st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
