[Bug 1187722] [NEW] dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information

[Robie Basak]

Public bug reported:

This causes an FTBFS in golang. See:
https://launchpad.net/ubuntu/+source/golang/2:1.1-1/+build/4578681

Affected: dpkg 1.16.10ubuntu1
Not affected: dpkg 1.16.10

I believe the difference is caused by Steve McIntyre's armhf detection patch
applied in the Ubuntu dpkg delta.

For convenience, I attach a golang armhf binary which dpkg-shlibdeps
doesn't work with. The error is:

dpkg-shlibdeps: error: couldn't find library libpthread.so.0 needed by /tmp/go (ELF format: 'elf32-littlearm-sfabi'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library libc.so.6 needed by /tmp/go (ELF format: 'elf32-littlearm-sfabi'; RPATH: '')
dpkg-shlibdeps: error: couldn't find library ld-linux-armhf.so.3 needed by /tmp/go (ELF format: 'elf32-littlearm-sfabi'; RPATH: '')
dpkg-shlibdeps: warning: binaries to analyze should already be installed in their package's directory
dpkg-shlibdeps: error: cannot continue due to the errors listed 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 set LD_LIBRARY_PATH.

The cause is that "readelf -A -- /tmp/go" doesn't produce any output. The
arm-specific handling in Dpkg::Shlibs::Objdump then errnoneously decides that
this means that the binary is "elf32-littlearm-sfabi", which mismatches its
dependencies.  This causes it to fail, when in fact there is no problem with
the binary's linkage or execution.

Is it a requirement for armhf binaries to have Tag_ABI_VFP_args? I'm not sure
whether the ABI spec actually requires this in order for a binary to be
expected to dynamically link against a libc that does declare the tag. Even if
so, does it make sense for dpkg to handle this condition more gracefully?

Is there a spec which defines a requirement to have Tag_ABI_VFP_args set, so
that we may refer golang upstream to it for a fix? Or is golang producing valid
binaries and dpkg-shlibdeps is buggy?

** Affects: dpkg (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: golang (Ubuntu)
     Importance: High
         Status: Confirmed


** Tags: armhf ftbfs

** Attachment added: "Example of an armhf binary that does not declare architecture specific information and causes dpkg-shlibdeps to fail"
   https://bugs.launchpad.net/bugs/1187722/+attachment/3695099/+files/go

** Also affects: golang (Ubuntu)
   Importance: Undecided
       Status: New

** Changed in: golang (Ubuntu)
       Status: New => Confirmed

** Changed in: golang (Ubuntu)
   Importance: Undecided => High

** Tags added: armhf ftbfs

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dpkg in Ubuntu.
https://bugs.launchpad.net/bugs/1187722

Title:
  dpkg-shlibdeps fails on armhf ELF binaries that do not define
  architecture specific information

Status in “dpkg” package in Ubuntu:
  New
Status in “golang” package in Ubuntu:
  Confirmed

Bug description:
  This causes an FTBFS in golang. See:
  https://launchpad.net/ubuntu/+source/golang/2:1.1-1/+build/4578681

  Affected: dpkg 1.16.10ubuntu1
  Not affected: dpkg 1.16.10

  I believe the difference is caused by Steve McIntyre's armhf detection patch
  applied in the Ubuntu dpkg delta.

  For convenience, I attach a golang armhf binary which dpkg-shlibdeps
  doesn't work with. The error is:

  dpkg-shlibdeps: error: couldn't find library libpthread.so.0 needed by /tmp/go (ELF format: 'elf32-littlearm-sfabi'; RPATH: '')
  dpkg-shlibdeps: error: couldn't find library libc.so.6 needed by /tmp/go (ELF format: 'elf32-littlearm-sfabi'; RPATH: '')
  dpkg-shlibdeps: error: couldn't find library ld-linux-armhf.so.3 needed by /tmp/go (ELF format: 'elf32-littlearm-sfabi'; RPATH: '')
  dpkg-shlibdeps: warning: binaries to analyze should already be installed in their package's directory
  dpkg-shlibdeps: error: cannot continue due to the errors listed 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 set LD_LIBRARY_PATH.

  The cause is that "readelf -A -- /tmp/go" doesn't produce any output. The
  arm-specific handling in Dpkg::Shlibs::Objdump then errnoneously decides that
  this means that the binary is "elf32-littlearm-sfabi", which mismatches its
  dependencies.  This causes it to fail, when in fact there is no problem with
  the binary's linkage or execution.

  Is it a requirement for armhf binaries to have Tag_ABI_VFP_args? I'm not sure
  whether the ABI spec actually requires this in order for a binary to be
  expected to dynamically link against a libc that does declare the tag. Even if
  so, does it make sense for dpkg to handle this condition more gracefully?

  Is there a spec which defines a requirement to have Tag_ABI_VFP_args set, so
  that we may refer golang upstream to it for a fix? Or is golang producing valid
  binaries and dpkg-shlibdeps is buggy?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1187722/+subscriptions