** Description changed:
+ [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?
** Also affects: dpkg (Ubuntu Precise)
Importance: Undecided
Status: New
** Also affects: golang (Ubuntu Precise)
Importance: Undecided
Status: New
** No longer affects: golang (Ubuntu Precise)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1187722
Title:
dpkg-shlibdeps fails on armhf ELF binaries that do not define
architecture specific information
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1187722/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
