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 anyway. > > 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 binutils-multiarch. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpIsc4p92rQw.pgp
Description: PGP signature