[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Building a gdb-multiarch and binutils-multiarch with --enable-targets=all

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:
 dh_strip -s --dbg-package=zlib1g-dbg
 strip: Unable to recognise the format of the input file
 dh_strip: strip --remove-section=.comment --remove-section=.note
 --strip-unneeded debian/zlib1g/lib/libz.so. 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:

 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

Reply to: