Your message dated Tue, 29 Jan 2019 10:55:58 +0100 with message-id <[email protected]> and subject line Re: Bug#816346: dpkg-dev: dpkg-shlibdeps should recognize both host and target objects has caused the Debian Bug report #816346, regarding dpkg-dev: dpkg-shlibdeps should recognize both host and target objects 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.) -- 816346: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816346 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: dpkg-dev Version: 1.18.4 Severity: normal Hello, In Objdump.pm, we use debarch_to_gnutriplet(get_host_arch()).'-objdump'; to run dpkg-shlibdeps on package objects. When building a cross-compiler, this is however not working. The cross-compiler itself is fine (since it's host), but the cross-compiler package also ships a few *target* objects, and for them one would have to use something like debarch_to_gnutriplet(get_target_arch()).'-objdump'; That however doesn't seem to exist in libdpkg-perl yet. Also, dpkg-shlibdeps will probably need to try both, because it can't know which objects are for the host or for the target. Otherwise, we for instance get this while building a cross gcc: dpkg-shlibdeps -Tdebian/gcc-5-x86-64-linux-gnu.substvars debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-5 debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcov-5 debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcov-tool-5 debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-ar-5 debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-ranlib-5 debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-nm-5 debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/collect2 debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/lto1 debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/plugin/libcc1plugin.so.0.0.0 /usr/bin/objdump: debian/libgcc1/lib/x86_64-linux-gnu/libgcc_s.so.1: File format not recognized That happens when the build and host are a 32bit architecture which doesn't have multilib support and target is a 64bit architecture, and thus its native objdump probably does not understand 64bit binaries. Samuel -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dpkg-dev depends on: ii base-files 9.5 ii binutils 2.26-4 ii bzip2 1.0.6-8 ii libdpkg-perl 1.18.4 ii make 4.1-6 ii patch 2.7.5-1 ii xz-utils 5.1.1alpha+20120614-2.1 Versions of packages dpkg-dev recommends: ii build-essential 12.2 ii clang-3.5 [c-compiler] 1:3.5.2-3 ii clang-3.6 [c-compiler] 1:3.6.2-3 ii fakeroot 1.20.2-1 ii gcc [c-compiler] 4:5.3.1-1 ii gcc-4.8 [c-compiler] 4.8.5-4 ii gcc-4.9 [c-compiler] 4.9.3-12 ii gcc-5 [c-compiler] 5.3.1-8 ii gcc-6 [c-compiler] 6-20160109-1 ii gnupg 1.4.20-4 ii gnupg2 2.1.11-5 ii gpgv 1.4.20-4 ii libalgorithm-merge-perl 0.08-3 Versions of packages dpkg-dev suggests: ii debian-keyring 2016.01.20 -- no debconf information -- Samuel <D> I hated the Mighty Mouse in the Apple Store every time I played with it. I hated the Mighty Mouse at work whenever I set up a Mac for somebody. <D> I decided to give it one last chance when I set up my new Mac <D> And golly, I like it at home. <D> Maybe mine is defective in a way that makes it good.
--- End Message ---
--- Begin Message ---Hi! On Fri, 2016-11-04 at 04:56:25 +0100, Guillem Jover wrote: > Control: tag -1 moreinfo > On Tue, 2016-03-01 at 02:00:16 +0100, Samuel Thibault wrote: > > Package: dpkg-dev > > Version: 1.18.4 > > Severity: normal > > > When building a cross-compiler, this is however not working. The > > cross-compiler itself is fine (since it's host), but the cross-compiler > > package also ships a few *target* objects, and for them one would have > > to use something like > > > > debarch_to_gnutriplet(get_target_arch()).'-objdump'; > > > > That however doesn't seem to exist in libdpkg-perl yet. Also, dpkg-shlibdeps > > will probably need to try both, because it can't know which objects are > > for the host or for the target. > > > > Otherwise, we for instance get this while building a cross gcc: > > > > dpkg-shlibdeps -Tdebian/gcc-5-x86-64-linux-gnu.substvars > > debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-5 > > debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcov-5 > > debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcov-tool-5 > > debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-ar-5 > > debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-ranlib-5 > > debian/gcc-5-x86-64-linux-gnu/usr/bin/x86_64-linux-gnu-gcc-nm-5 > > debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/collect2 > > debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/lto1 > > debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper > > debian/gcc-5-x86-64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/5/plugin/libcc1plugin.so.0.0.0 > > /usr/bin/objdump: debian/libgcc1/lib/x86_64-linux-gnu/libgcc_s.so.1: File > > format not recognized > > > > That happens when the build and host are a 32bit architecture which > > doesn't have multilib support and target is a 64bit architecture, and > > thus its native objdump probably does not understand 64bit binaries. > > I'm assuming that this libgcc_s.so.1 (and other) target files are ending > up on a package for the "wrong" architecture compared to what they > really are (say libgcc1_VERSION_HOST.deb instead of > libgcc1_VERSION_TARGET.deb)? > > If so, I'd probably say that this is the same problem as with multilib > in general, trying to inject objects into packages that claim to be > for another architecture. And if so, I know this is not going to help > you, but I think trying to support the multilib model is just broken > and requires adding all kinds of hacks and ugly logic to cover what > to me seems to be broken by design. > > IMO canadian-cross compilers need to be built so that you end up with > stuff like: > > build == i386 > host == amd64 > target == mips > > compiler-mips_VERSION_amd64.deb > libsupportN_VERSION_mips.deb > > And compiler-mips would end up having a cross-arch dependency on > libsupportN. In addition for multilib canadian-cross compilers this can already be supported by calling dpkg-shlibdeps with the appropriate environment set by something like: dpkg-architecture -f -a $DEB_TARGET_ARCH -c "dpkg-shlibdeps ..." So, given the above, and as long as there are multilib compilers that need to be supported, this is something that can be solved in their packaging. I'm thus closing this now Thanks, Guillem
--- End Message ---
