Re: Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf
Hi!
On Tue, 2017-01-31 at 22:44:36 +0000, James Cowgill wrote:
> Package: dpkg
> Version: 1.18.21
> Severity: serious
> X-Debbugs-CC: debian-arm@lists.debian.org
> [Disclaimer: I'm not an ARM porter and I don't really know much about
> the ARM psABI]
>
> The new ABI mismatch detector seems to be a bit too strict on armel and
> armhf. The detector forces the ELF_FLAG_ARM_HARD_FLOAT and
> ELF_FLAG_ARM_SOFT_FLOAT flags to be equal on both the library and its
> user but checking ABI comparability doesn't seem that simple.
Indeed. :(
> For example, on armel linking against libgsm.so currently gives this:
>
> $ dpkg-shlibdeps -v -e../a.out -Ttest
> dpkg-shlibdeps: debug: >> Scanning ../a.out (for Depends field)
> dpkg-shlibdeps: debug: Skipping lib /usr/lib/arm-linux-gnueabi/libgsm.so.1, libabi=0x0101002805000000 != objabi=0x0101002805000200
> dpkg-shlibdeps: error: cannot find library libgsm.so.1 needed by ../a.out (ELF format: 'elf32-littlearm' abi: '0101002805000200'; RPATH: '')
> dpkg-shlibdeps: debug: Library libc.so.6 found in /lib/arm-linux-gnueabi/libc.so.6
> dpkg-shlibdeps: debug: Using symbols file /var/lib/dpkg/info/libc6:armel.symbols for libc.so.6
> dpkg-shlibdeps: warning: binaries to analyze should already be installed in their package's directory
> dpkg-shlibdeps: error: cannot continue due to the error above
> Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file.
> To help dpkg-shlibdeps find private libraries, you might need to use -l.
>
> 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.
> This was first seen with wine:
> https://buildd.debian.org/status/fetch.php?pkg=wine&arch=armhf&ver=1.8.6-4&stamp=1485847439&raw=0
> https://buildd.debian.org/status/fetch.php?pkg=wine&arch=armel&ver=1.8.6-4&stamp=1485847712&raw=0
>
> But there seem to be some other recent build failures relating to this
> as well.
Oh, wow, I'm not sure this is very kosher, but if it is causing build
failures, then it does not matter much.
I'm preparing an upload right now.
Thanks,
Guillem
Reply to: