[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, 18 Jan 2011 00:08:17 +0100
Loïc Minier <lool@dooz.org> wrote:

> On Mon, Jan 17, 2011, Neil Williams wrote:
> > Has anyone actually had time to test Joey's contention that dh_strip
> > is not the right solution to fix because of packages using `install
> > -s` in their Makefiles?
>  If you refer to his reply in the bug, both Simon and I got back to him
>  in this bug

Neither comment appears to have convinced Joey. We need some proper
explanation and test build results to persuade him.

> > Can't we just have a cross-strip package instead? That, IMHO, is the
> > correct fix. Strip back binutils-multiarch to only provide strip
> > (nicely recursive too). Then you can have all the supported
> > architectures and maybe even retain the full version but NOT make it
> > part of a default cross-building install. It could be as simple as
> > only packaging strip into a new binary package when building
> > binutils-multiarch.
>  Providing only strip in binutils-multiarch wont help you with its size;
>  the bulk of the size is in the bfd libs which I quoted in my original
>  email.  Besides, cross-objdump is useful in at least dpkg-shlibdeps,
>  and I can think of good uses for cross-size, cross-readelf or cross-nm
>  (and the obvious cross-as).

Useful doesn't mean that they need to be packaged as a dependency of
dpkg-cross. Something to do strip in a cross-build is clearly
mandatory for cross-builds to work, we need to determine whether
something for dh_makeshlibs is mandatory too.

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.

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.

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

> > Loic: what problem did you find with dh_makeshlibs? When I tested with
> > the binutils package for the armel cross toolchain without
> > binutils-multiarch installed, I didn't get problems with
> > dh_makeshlibs, only with strip.
>  Which package did you try?  I think I hit it with some leaf lib package
>  like zlib, but I'm not sure wihch one.

I tried a few simple packages (popt is a frequent test case of mine,
qof is another). We need a more rigorous test with results available
online for everyone to pick apart.

> > Can you file a new bug for that one with full details please?
>  I'm not sure, it's the same issue as dh_strip; I could split it out,
>  but I don't think it's worth it

I think it is worth splitting out. We need the raw data if Joey is to
change the debhelper behaviour.

> 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


Neil Williams

Attachment: pgpIsc4p92rQw.pgp
Description: PGP signature

Reply to: