Control: tag -1 moreinfo Hi!
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. Thanks, Guillem
