Your message dated Wed, 6 Sep 2017 04:00:04 +0200
with message-id <[email protected]>
and subject line Re: Bug#846211: dpkg-dev: dpkg-shlibdeps execs objdump on
wrong lib architecture
has caused the Debian Bug report #846211,
regarding dpkg-dev: dpkg-shlibdeps execs objdump on wrong lib architecture
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
846211: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846211
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg-dev
Version: 1.17.27
Severity: important
Dear Maintainer,
This happens on an odrobian hybrid installation: 64 bits kernel with
32 bits userland. gcc -v says:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.9.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper
Target: arm-linux-gnueabihf
debuild fails with the following output:
dh_shlibdeps -O--parallel
objdump: /lib/aarch64-linux-gnu/libpthread.so.0: File format not recognized
dpkg-shlibdeps: error: objdump gave error exit status 1
dh_shlibdeps: dpkg-shlibdeps -Tdebian/libupnp6.substvars
debian/libupnp6/usr/lib/arm-linux-gnueabihf/libthreadutil.so.6.0.4 ... returned
exit code 1
debian/rules:14: recipe for target 'binary' failed
Workaround: Just forbidding (chmod 0) access to
/lib/aarch64-linux-gnu/ and /usr/lib/aarch64-linux-gnu/ fixes the
problem (the package build succeeds, the packages are ok), so it would
appear that someone is looking in the wrong places.
-- System Information:
Debian Release: 8.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (aarch64)
Foreign Architectures: arm64
Kernel: Linux 3.14.29-14-odrobian+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages dpkg-dev depends on:
ii base-files 8+deb8u6
ii binutils 2.25-5
ii bzip2 1.0.6-7+b3
ii libdpkg-perl 1.17.27
ii make 4.0-8.1
ii patch 2.7.5-1
ii xz-utils 5.1.1alpha+20120614-2+b3
Versions of packages dpkg-dev recommends:
ii build-essential 11.7
ii fakeroot 1.20.2-1
ii gcc [c-compiler] 4:4.9.2-2
ii gcc-4.9 [c-compiler] 4.9.2-10
ii gnupg 1.4.18-7+deb8u3
ii gpgv 1.4.18-7+deb8u3
ii libalgorithm-merge-perl 0.08-2
Versions of packages dpkg-dev suggests:
ii debian-keyring 2015.04.10
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi!
On Tue, 2017-02-07 at 14:45:43 +0100, Guillem Jover wrote:
> On Wed, 2016-11-30 at 08:25:12 +0100, Jean-Francois Dockes wrote:
> > Guillem Jover writes:
> > > Control: tags -1 moreinfo
> > > Control: severity -1 normal
> > I am not trying to cross-compile (this is the whole point of using this
> > sytem actually: a reasonably fast native ARM system to build things).
> >
> > The userland is ARM 32 bits: the gcc ouput above is the one from the normal
> > system compiler. ARM64 is present on the system as a foreign architecture,
> > and just used for a few commands, specific to building system images as far
> > as I can see.
> >
> > dpkg-buildpackage is invoked from debuild, which in turn invokes
> > dh_shlibdebs. I am copying a full buildlog at the end (I cut out most of
> > the CC lines, as just bit repetitive and boring...). Setting
> > DEB_BUILD_ARCH=armv7l works for raw dpkg-buildpackages (as an alternative
> > to forbidding access to the aarch64 dirs), but not for debuild (for which
> > the directory interdiction works).
>
> Ok, I think the latest changes dpkg with respect the ELF ABI detector
> should have improved the problem you are facing here. I'd appreciate
> if you could test dpkg 1.18.22, and report back?
>
> There are still some scenarios that will not be handled properly,
> which I'd like to fix during the 1.19.x cycle, for example between
> armel and armhf, or linux-i386 and kfreebsd-i386, but those are
> unrelated to this bug.
>
> So if things have actually improved now, we can close this bug report.
Ok, closing now, assuming this has been fixed. If that's not the case,
please feel free to reopen it.
Thanks,
Guillem
--- End Message ---
