dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dpkg (Ubuntu) |
Fix Released
|
Undecided
|
Adam Conrad | ||
Precise |
Fix Released
|
Undecided
|
Adam Conrad | ||
Quantal |
Won't Fix
|
Undecided
|
Unassigned | ||
Raring |
Won't Fix
|
Undecided
|
Unassigned | ||
golang (Ubuntu) |
Fix Released
|
High
|
Adam Conrad | ||
Quantal |
Invalid
|
Undecided
|
Unassigned | ||
Raring |
Invalid
|
Undecided
|
Unassigned |
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/
[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:/
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-
dpkg-shlibdeps: error: couldn't find library libc.so.6 needed by /tmp/go (ELF format: 'elf32-
dpkg-shlibdeps: error: couldn't find library ld-linux-armhf.so.3 needed by /tmp/go (ELF format: 'elf32-
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:
this means that the binary is "elf32-
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?
Related branches
description: | updated |
no longer affects: | golang (Ubuntu Precise) |
Changed in dpkg (Ubuntu Precise): | |
assignee: | nobody → Adam Conrad (adconrad) |
status: | New → In Progress |
Changed in golang (Ubuntu Quantal): | |
status: | New → Invalid |
Changed in golang (Ubuntu Raring): | |
status: | New → Invalid |
Changed in dpkg (Ubuntu Quantal): | |
status: | New → Won't Fix |
Changed in dpkg (Ubuntu Raring): | |
status: | New → Won't Fix |
@Steve
I'd appreciate your feedback on this. Am I right in assuming that we need your patch for armel/armhf multiarch? Is my diagnosis correct? Do you think that dpkg should behave correctly in this case, or cannot be expected to do so?