Re: Multiarching perl
On Thu, Jul 19, 2012 at 01:16:19PM +0100, Wookey wrote:
> 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.
Yes, as long as those modules are pure Perl. However, many of them
(the so-called XS modules) are dynamically loadable plugins that need
to match the architecture and compile options of the Perl interpreter
that's loading them.
> 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).
That's right. These things usually embed a Perl interpreter.
> 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.
The latter are those XS modules that come with the Perl core distribution.
Most non-trivial applications embedding Perl are going to need at least
some of them.
> 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?
I expect that everything in /usr/lib/perl/$VERSION needs to go in a
multiarch qualified path. They are either architecture dependent
themselves (*.ph, Config.pm, etc.) or tightly coupled with the
corresponding *.so files.
> 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?
Yes, it's all to do with that. The perl-base package is Essential:yes,
so it needs to stay functional even when its dependencies are not
configured. If libperl.so.$VERSION was in a separate package, upgrading
either of the libperl package or the perl-base package would potentially
break /usr/bin/perl.
The i386 case is special because of performance reasons (register
starvation on that architecture). /usr/bin/perl is statically
linked there and so libperl.so.5.14.2 can go in libperl5.14.
> 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).
Nobody depends on perl-base as it's Essential:yes. You may be thinking
about the 'perl' package.
> 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.
The essential functionality of perl-base includes the part of the standard
library in /usr/{share,lib}/perl/$VERSION that's shipped in the package.
So those .sos have the same lockstep requirements and can't really
(easily?) be separated out into libperl.
However, if they aren't split away from perl-base, a foreign architecture
application embedding libperl won't have the binary parts of the standard
library in perl-base available at all, which is clearly unacceptable.
To summarize, I see two somewhat separate problems:
- you can't have multiple architecture versions of libperl.so.5.14.2 installed
as long as it goes in perl-base, but the lockstep requirements mean it can't
be moved away as long as /usr/bin/perl is dynamically linked.
We could solve this by linking /usr/bin/perl statically everywhere.
I expect this comes with a price at least on memory footprint.
It's also against the general trend of linking everything dynamically.
- the corresponding lockstep problem for the perl-base parts of standard
library; statical linking won't help here.
The best I can think of is having perl-base install its files into a
separate, possibly even non-multiarch qualified path, and libperl5.14 (or
something else?) having a copy of them going into arch-qualified paths like
/usr/lib/$triplet/perl. This would essentially duplicate the perl-base
contents in two packages, which may or may not be a cost worth paying.
Will need to think more about this.
--
Niko Tyni ntyni@debian.org
Reply to: