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:
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
Reply to: