[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Crossbuilding with multiarched perl



+++ 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
> 
> This is work in progress, no guarantees about not rewriting history yet.

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.
Probably not without a bit more work.

So here is what I found. Clarifications would be most appreciated.

This modules uses MakeMaker (Makefile.PL generates Makefile on each
build)
As supplied it uses the wrong-arch compiler, linker, and include path.

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?

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? 

I can get the package to build by doing:
DEB_HOST_GNU_TYPE       := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)

$(PERL) Makefile.PL INSTALLDIRS=vendor CC=$(DEB_HOST_GNU_TYPE)-gcc
$(MAKE) PERL_INC=/usr/lib/$(DEB_HOST_GNU_TYPE)/perl/5.14.2/CORE OPTIMIZE="$(CFLAGS)" LD_RUN_PATH=""

Trying to set INC (or PERL_INC) on the Makefile.PL line doesn't work.
passing CC and LD on the Make line also works.

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' 

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.

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...

Does it matter if that PERL_INC path is 5.14.2 or 5.14 ? I see both
exist and are symlinked. Is one more correct?

This build completes and files are the right architecture. There is some whinging about 
"PERL_UNUSED_DECL" redefined [enabled by default]
but the native build does that too, so I guess it's OK

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/

Which of the hundreds of *INSTALL variables controls this? 
On a native build it comes out in 
/lib/x86_64-linux-gnu/perl5/auto/Term/ReadKey/

I've peered at the variables a bit but failed to work out what the
right way to fix this is.

So, have I missed some 'nice' way to do all this, or is the above
probably about right?

And so far as I can tell the actual perl multiarch setup is working
correcly. Nice :-)

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


Reply to: