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

[Robie Basak]

Rebuilt golang 2:1.1.2-2ubuntu1 in a Precise schroot.

On amd64, it works with dpkg 1.16.1.2ubuntu7.2 and the produced go binary works.
On armhf, the build fails with dpkg 1.16.1.2ubuntu7.1 as expected.
On armhf, the build works with dpkg 1.16.1.2ubuntu7.2 and the produced go binary works.

** Tags removed: verification-needed
** Tags added: verification-done

-- 
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:
  Fix Released
Status in “golang” package in Ubuntu:
  Fix Released
Status in “dpkg” source package in Precise:
  Fix Committed

Bug description:
  [Impact]

  This causes a build failure on armhf for any package that uses a
  toolchain that does not provide the optional ELF architecture specific
  tags like the gcc toolchain does. Example: golang. This stops us
  building armhf golang packages on Precise, such as the juju-core
  precise backport.

  [Stable Fix]

  Before reading any architecture specific tags, consider the ELF header
  flags field first for a match against the new "hard-float ABI" flag,
  and use this information over architecture specific tags if available.

  [Development Fix]

  Exactly the same patch as the stable fix.

  [Test Case]

  Attempt to build the unmodified golang source package from Saucy on
  Precise armhf.

  Expected results: successful build.

  Failure results:

  Errors of the form: dpkg-shlibdeps: error: couldn't find library
  libpthread.so.0 needed by debian/golang-go/usr/bin/go (ELF format:
  'elf32-littlearm-sfabi'; RPATH: '').

  [Regression Potential]

  The change is limited to dpkg-shlibdeps on ARM ELF binaries only, so
  should only affect rebuilds or backports.

  [Original 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