On Tue, Jan 18, 2011, Neil Williams wrote: > Neither comment appears to have convinced Joey. We need some proper > explanation and test build results to persuade him.
Do you think you could vouch in as well? That would make 3 voices asking for it instead of 2. Concerning dh_makeshlibs, I just tested and I didn't face any issue when trying to use the amd64 objdump on an armel binary. I discussed this with Ulrich Weigand who works on GDB upstream, and he explained that reading the SONAME from an ELF file is relatively easy, even if the target binary is from an architecture with a different number of bits or endianess. I didn't actually check whether it would work for instance from armel to read an amd64 binary, but it's likely it would. This does mean we probably don't technically need to call cross-objdump in dh_makeshlibs, but I think I did that because I had to run cross-objdump in dpkg-shlibdeps and such. It seemed sensible to do the same thing in all places which call binutils. I would still postulate that it's best to use a cross-objdump, mostly to not forget about this practice if e.g. dh_makeshlibs gets copied or extended. > So one possible way would be to return to the bad old days of diverting > dh_strip (as we used to divert dpkg-buildpackage) with a test package > and then do a series of test cross builds with a binutils installed > from the cross toolchain packages and a dh_strip diversion in a clean > chroot with no binutils-multiarch. Geez, this is really backwards This is long fixed in Ubuntu because, well, the fix was just applied; I would suggest you use some kind of staging archive for cross-build fixes, or set cross-buildability of a subset of the archive a a goal for squeeze+1 and get permission to NMU for old patches which don't cause any regression, but where the maintainer is too busy. > Run that test for something like a complete Debian debootstrap package > set and put the results online, then we have the data which should > persuade Joey that binutils-multiarch is really only optional and a > fixed dh_strip (possibly with a fix to dh_makeshlibs too) would > dramatically simplify cross building environments. I just ran a cross-build test on zlib, and I think it will fail pretty much in the same way no matter what the arch: any package: http://hudson.dooz.org/job/xdeb-test/16/console dh_strip -s --dbg-package=zlib1g-dbg strip: Unable to recognise the format of the input file `debian/zlib1g/lib/libz.so.1.2.3.4' dh_strip: strip --remove-section=.comment --remove-section=.note --strip-unneeded debian/zlib1g/lib/libz.so.1.2.3.4 returned exit code 1 make: *** [binary-arch] Error 2 (this is in an Ubuntu chroot, after reverting the dh_strip fixes) > There's no point expecting this to be changed before Squeeze is > released and it does mean *all* cross-builds depending on debhelper >=8 > or similar, so a diversion package may be needed by quite a few people > anyway. Diversions are evil; I would find it easier to just provide an overlay archive as a service to people who need to cross-build Debian. We are also trying to improve the Ubuntu packages to be more cross-build friendly when that's not too intrusive. > > How many of these architectures are REALLY used with a cross-debugger? > > Seriously, apart from arm(*), powerpc(*) and maybe mips(*), do we > > really need the default package to include loads more? > > > > How many cross-building users cross-build for more than one > > architecture? > > > > How many of those are all just variants of one main type? (i.e. > > subtypes of various ARM platforms) > > > > Who are these people who are cross-building for armel, mips, sparc, > > powerpc, hppa, ia64 and m68k all on the same machine? (and are any of > > them still sane?) > > Those questions also need to be answered properly before we go bloating > binutils-multiarch. TBH, I don't think these are the right questions This is the current set of triplets which binutils-multiarch: alpha-linux-gnu arm-linux-gnu armel-linux-gnu hppa-linux-gnu i486-linux-gnu ia64-linux-gnu m68k-linux-gnu m68k-rtems mips-linux-gnu mipsel-linux-gnu mips64-linux-gnu mips64el-linux-gnu powerpc-linux-gnu powerpc64-linux-gnu s390-linux-gnu s390x-linux-gnu sh-linux-gnu sh64-linux-gnu sparc-linux-gnu sparc64-linux-gnu x86_64-linux-gnu m32r-linux-gnu spu Can you spot the errors? I could spot that arm-linux-gnu and armel-linux-gnu are listed, but aren't supported anymore, and arm-linux-gnueabi is missing. Some oddballs too, like m68k-rtems! This wouldn't happen with --enable-targets=all. I think we shouldn't spend our time maintaining this list to save some MBs of a package which is only used by a subset of the developers on systems/chroots which get to install *huge* build-deps to build packages anyway. Also, --enable-targets=all is actually build-tested before release; other combinations less so. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-embedded-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110118202141.ga16...@bee.dooz.org
