Re: linking perl statically against libperl
On Sun, Apr 19, 2015 at 02:25:55PM +0200, Axel Beckert wrote:
> Niko Tyni wrote:
> > Cons:
> > E increased memory usage on systems running multiple perl processes
> > F possibly increased startup time for short perl scripts
> > (but that may be a non-issue due to caching anyway?)
>
> This sounds rather concerning to me. The again, I've never noticed any
> issues on i386 and kfreebsd-i386.
Right. I suspect the choice between static and dynamic linking doesn't
matter much on most systems in the real world, but I'd be interested
in arguments to the contrary.
> Since you wrote in #781476 that both, statically and dynamically
> linked perl binaries are built anyways and then one is thrown away
> depending on the architecture, what about letting the user
> respectively administrator choose?
I think this is overkill and we don't need more choice here.
> Either by
>
> * shipping both in the perl package and using /etc/alternatives/perl
> to choose between the two (perl-dynamic and perl-static) for
> /usr/bin/perl, or
Even though update-alternatives is nowadays written in C and not
Perl, I still wouldn't trust the alternatives system enough to handle
Essential:yes functionality.
> * by providing two conflicting packages perl-base and
> perl-base-static.
dpkg cries loudly (and rightly so) if you try to remove an Essential:yes
package like perl-base.
What I could do is to ship the dynamically linked binary separately
as something else than /usr/bin/perl, as it's basically just a tiny
wrapper for libperl. It's a bit tempting to put it in libperl5.20
and anticipate future Multi-Arch:same libperl packages by naming it
/usr/bin/perl-x86_64-linux-gnu or something like that...
--
Niko Tyni ntyni@debian.org
Reply to: