Re: Multiarching perl
On Thursday 19 July 2012 14:16:19 Wookey wrote:
> 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).
They also depends on libperl5.14. This is often the case when a program embeds
a perl interpreter so Perl code (or library) can be run from within. ( so
people are running Perl code without being aware of it ;-) ). See perlembed
man page for more details.
> 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
This needs to be checked with the people who build Perl for Debian. (debian-
perl team is more about pacakging modules). I hope that these people are
reading.
> but I've just noticed that
> there are also a set of
> /usr/lib/perl/5.14.2/auto/*.so libraries.
This libraries are part of Perl libraries which also use C libraries (a bit
like java JNI stuff). Using C libraries is most often done with XS language
(which is C with Perl specific macros)
> So my first question is what do they do? Do other thing link against
> them?
I don't think so. lib in auto directories are loaded by Perl using dl_open.
> Which other things need to know the path to them?
Perl ABI changes for every major version so the XS libs need to be recompiled.
> 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?
This may be possible, but I don't remember the Perl compilation that well (I
used to compile Perl for my HPUX box in the last century)
> 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?
From libperl description:
This package is required by programs which embed a Perl interpreter to
ensure that the correct version of `perl-base' is installed. It
additionally contains the shared Perl library on architectures where the
perl binary is linked to libperl.a (currently only i386, for performance
reasons). In other cases the actual library is in the `perl-base' package.
> 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?
Ahem, I'll let others fill the blank...
> 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.
Some stuff will need to be taken care of for the XS libraries. I will be able
to spare some time to tinker with libconfig-augeas-perl (an XS lib) in
September if need be.
Hope this helps
--
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Reply to: