Multiarching perl
(please cc: I am not on this list)
Hello perl-people. I'm afraid I've got a lot of awkward questions
about how perl is put together. Some people at debconf were very
helpful but weren't really 'perl core' people so were a bit vague on
the details. I've now had a (very) quick look at things myself and
find myself off the edge of my knowledge so it's time to try and find
some clue here.
The core issue here is that Debian is now using multiarch for
libraries and for cross-building. For the latter to work core packages
like perl (and *SPIT* python :-) need to be multiarched so that
cross-arch build-deps get correctly installed and things can link
aginst the library of the correct architecture.
There is a lot of info on how this works in
https://wiki.ubuntu.com/MultiarchCross and the base multiarch spec at:
https://wiki.ubuntu.com/MultiarchSpec
and on implementation at: http://wiki.debian.org/Multiarch/Implementation
For most perl stuff everything is architecture independent and
multiarch is mostly-irrelevant. modules refer to other perl modules
and thing use perl to run perl code during the build. This is all
fine and already works.
The tricky bit comes with stuff which links against libperl itself.
There seem to be plenty of things which build-dep on libperl
specifically, which I presume means they may link against the library?
(courier, exim4, imagemagick, postgres, libapache2-mod-perl2, swig,
mimedefang are some common examples).
This means we need to make libperl for the host architecture (the one
we are building for) co-installable with the build architecture (the
one we are building on). This initially looked simple enough: move
/usr/lib/libperl.so.5.14.2 to /usr/lib/$DEB_HOST_MULTIARCH/libperl.so.5.14.2
but I've just noticed that there are also a set of
/usr/lib/perl/5.14.2/auto/*.so libraries.
So my first question is what do they do? Do other thing link against
them? Which other things need to know the path to them? Is it going to
be problematic to move them to
/usr/lib/$DEB_HOST_MULTIARCH/perl/5.14.2/auto/ without also moving all
the arch-independent stuff in /usr/lib/perl/5.14.2 down into there as
well?
The other issue is that /usr/lib/libperl.so.5.14.2 isn't actually in
libperl (except on i386). It's in perl-base. Can someone explain the
thinking here? It doesn't matter a great deal but I suspect some
understanding will help avoid me getting it all wrong. Is it anything
to do with ensuring perl and its libraries are upgraded in lockstep?
If the libs are left in perl-base then we mark perl-base Multi-Arch:
allowed so that it can be depended-on either as an arch-independent
tool (for running perl scripts) or as an arch-dependent library (for
linking against). If the .sos are all separated out into libperl then
we have separated those functions by package and libperl becomes M-A:
same and perl-base become M-A: foreign.
And finally are there any other bits of perl that are in fact
arch-dependent that I should know about?
I'm sure that's all rather confusing if you haven't been following the
multiarch stuff in any detail. Sorry about that - I have tried to be
clear - do ask if I have not been.
So, can anyone help me with understanding how perl is a) put together
b) used and c) packaged so that I can make a perl multiarch patch?
There is a whole other set of questions I have about making
cross-building perl itself less painful, but I think those are best
addressed upstream. And anyway, one thing at a time ;-)
TIA
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: