Re: Crossbuilding with multiarched perl
On Thu, Sep 27, 2012 at 02:43:29AM +0100, Wookey wrote:
> +++ Niko Tyni [2012-09-21 22:13 +0300]:
> >
> > I've pushed the current state on the 'ntyni/multiarch-5.14' branch of
> > git://git.debian.org/perl/perl.git
> Right. I've tried cross-building an XS-using module using the M-A:
> perl you did. I've spent a merry few hours flapping about, mostly
> because I don't know how any of this works. So far as I can tell your
> packages-split works fine.
>
> I used the libterm-readkey-perl module as an example.
> I got it to build OK, but I don't know if it's actually right.
I've been trying to find the time to do some experiments myself, but
that seems to be hard, so here are some untested suggestions.
> In principle all the right info is in the
> /usr/lib/<triplet>/perl/5.14.2/Config.pm file in libperl5.14
> however I don't see any obvious way of making
> perl Makefile.PL read the HOST version instead of the BUILD version,
> and maybe that's not the right thing to do anyway as it'll just break
> the native perl?
Ideally,
perl -I /usr/lib/<triplet>/perl/5.14.2/ Makefile.PL
would work, but I expect it will fail when it encounters foreign
auto/*.so files.
If that's the case, you could try to copy
/usr/lib/<triplet>/perl/5.14.2/Config* to a separate directory and prepend
that to the search path as above. I think that should be enough for most
if not all cases.
I'm not sure how hard it would be to persuade perl to put the auto/*.so
files in an arch-qualified subdirectory.
> Also only the BUILD arch version of libperl5.14 is pulled in by the
> libterm-readkey-perl's Build-dep on perl so we only have the BUILD
> arch version by default. Is the HOST arch version on Config.pm the
> right way to get details needed for crossbuilding?
Absolutely. I suppose that means you'll need to install the HOST
version of the perl package. But isn't that the case for any library
build-dependencies too?
> If /usr/lib/x86_64-linux-gnu/perl/5.14.2/Config.pm had CC=
> 'x86_64-linux-gnu-gcc' instead of 'cc' then we would have the potential
> to use those Config.pm files to set the compiler. Currently they both
> just say 'cc' slightly uselessly. LD isn't listed, so also defaults to
> 'cc'
If it's guaranteed that <triplet>-gcc is equivalent to gcc on the native
architecture, I suppose we could use that unconditionally in the perl package.
That would mean adding
-Dcc=\'$archtriplet-gcc\'
in debian/config.debian. Feel free to try that.
> Ideally I'd just tell Makefile.PL what the BUILD and HOST arches were
> and it would work out the compiler name, linker name, include paths
> and linker paths all by itself. Is this functionality which simply
> doesn't exist at the moment? I didn't find much online suggesting it.
I'm pretty sure such functionality doesn't exist. ExtUtils::MakeMaker
gets all this information from Config.pm, as they may vary a lot
between perl installations.
> It also seems crufty that the rules file needs to know the perl
> version in order to pass a PERL_INC path. perl -V:version gets it in a
> sedable form - is that as good as it gets? Perl already knows its own
> version...
There's perl -V:archlib that you could use to for substitution
if you really need that. It would certainly be more robust than
constructing /usr/lib/<triplet>/perl/5.14.2 yourself. It would be
preferable to make perl read in the HOST Config.pm though, so
that you wouldn't need PERL_INC at all.
> The (arm) ELF file ReadKey.so ends up in
> /usr/lib/perl5/auto/Term/ReadKey/ which I presume is wrong in
> mulitarch-world and should be
> /usr/lib/arm-linux-gnueabihf/perl5/auto/Term/ReadKey/
Yeah, you should look at changing
-Dvendorarch=/usr/lib/perl5
in debian/config.debian of the perl package.
Hope this helps a bit,
--
Niko
Reply to: