On Sat, 23 Jan 2016 22:45:08 +0200 Niko Tyni <ntyni@debian.org> wrote: > Hi, > > I've been working on cross build support for src:perl, which has > been a sore point for quite some time. Current results are on the > ntyni/cross-5.22 branch on alioth (but might still get > rebased/rewritten): > > https://anonscm.debian.org/cgit/perl/perl.git/log/?h=ntyni/cross-5.22 > > Summary: Configure still needs runtime probes, but the resulting > probed configuration data can be fed into a cross build with a > separate binary package, currently called perl-config-data. This is > the same approach that Neil Williams worked on with > src:perl-cross-debian a couple of years ago, but we now build the > package from src:perl itself. \o/ that makes perl-cross-debian redundant (it only managed support for 5.18 which predates Jessie) and the update process became prohibitive. It's very good news that perl can handle this internally. > Apart from that, I've got cross builds fully working (tested on amd64 > -> mipsel) with crossbuild-essential et al. from sid. Many thanks to > those who have contributed to getting this stuff working in Debian, > it has all become a lot easier than it used to be. > > Bootstrapping a new architecture could be achieved by manually > preparing the configuration data package, probably by modifying one > for an existing similar architecture. I'm open to suggestions on how > to make this as easy as possible. If there is no similar arch, some notes on which variables relate to architecture-specific values used by a range of other packages (the list that ends up in dpkg-cross, like [0]) would be useful. In perl-cross-debian, config.sh.native stored most of that kind of data. Just having the full set of up to date arch-specific config will make it a lot easier to identify the elements that are common to all Debian systems, related architectures etc. That was the main failing with perl-cross-debian, getting the raw data. [0] https://sources.debian.net/src/dpkg-cross/2.6.11/config/cross-config.armhf/ > Thanks to past upstream work by Jess Robinson and Neil, this level of > cross build support needed only three upstream changes, one of which > is trivial and another (podlators) already merged. People wanting to > see the remaining issue of Configure cross-compiling support fixed are > invited to read https://rt.perl.org/Ticket/Display.html?id=124326 and > volunteer to help upstream. > > As a proof of concept, I've also implemented a 'stage1' build profile > that only builds the perl-config-data binary package. However, I'm not > really sure how useful that is. The idea there is that a functional > but slow Debian architecture could run just the configuration probes > natively (or reuse old configuration data on minor upgrades), and the > rest could be cross built. I suspect this doesn't help real > bootstrapping, as the various dpkg-dev tools require a > working /usr/bin/perl to put any package together in the first place. It could be a useful sanity check during the bootstrap process. Even without dpkg-dev tools, just having the commands to run manually can be helpful too - including anything specific to that release. > @Dominic and others on the src:perl side: the commits before the cross > related upstream changes are intended to be non-disruptive and could > (at least in theory) be merged into unstable straight away. Eyeballs > would be very welcome; the debian-cross list should probably be > dropped from that discussion. > > I'm not sure if it's viable to upload this into experimental at > this point; the buildds probably don't have #809730 fixed yet, > do they? Without that fix, sbuild applies the cross build dependency > on perl-config-data to native builds too and bails out straight away. > Also, we'll be needing experimental for staging 5.24 in a few months > so maybe it would be better to use a custom repository for testing > this? > > In the long run, I can see cross building eventually replacing our > current somewhat half-baked new architecture bootstrapping support > that is the reason we need to roll our own horrific debian/rules and > can't use debhelper et al. I think I'd want to see how this stuff > rebases on a couple of upstream releases first before declaring it > stable, though. > > In any case, I'd be interested in comments and thoughts on this. > Is it useful, or just a worthless workaround as long as the Configure > issues remain unsolved? Bootstrapping has proven to be a perpetual wheel, there's nearly always someone working on a bootstrap of some kind. It is definitely useful to have this configuration data, especially with a history and full arch coverage! Many thanks for continuing the work on this very difficult problem. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpHFOdxlNH8S.pgp
Description: OpenPGP digital signature