Recent advances in cross building src:perl

[Neil Williams]

On Sat, 23 Jan 2016 22:45:08 +0200
Niko Tyni <ntyni at 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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/perl-maintainers/attachments/20160123/7d44bb6d/attachment.sig>