Arch Linux

It's only built static, not shared:
$ pacman -Ql perl | grep libperl
perl /usr/lib/perl5/core_perl/CORE/libperl.a

I've seen debian installing libperl.so.* in /usr/lib/ btw.

What's the status on this? Is it even needed?

Yes, it's still needed to use collectd's perl plugin feature. :)

According to the INSTALL documentation, there is a significant performance penalty associated with building a libperl.so
See http://cpansearch.perl.org/src/DAPM/perl-5.10.1/INSTALL (section "Building a shared Perl library").
So -1 from me.

Ever thought about how old that documentation is? Solaris 2.5 x86... that's from the time when solaris was still called Slowlaris, at least on x86.

I think it's good to have a shared perl lib available. Perl doesn't bump that often, and it reduces the size of binaries that embed perl.

All right then. I've built 5.10.1 already. I'll build it again with a shared lib and will run some benchmarks. I'll report back soon.

OK, I have used perlbench (http://search.cpan.org/~gaas/perlbench-0.93/) to benchmark static perl vs libperl.so.
I have put the results at http://ankabut.net/varia/perlbench/
Overall there is still a significant penalty! Perhaps the advantage of having a dynamic library overweights this, but I am still not fully convinced.

Could it not be possible to provide a separately compiled libperl.so while keeping a statically compiled perl binary?
This should be manageable using split packages, but one should then find a way to hide libperl.so from perl while making it available to external applications. Just thinking aloud. Perhaps this is not really doable.

How does perlbench run its benchmark? Does it start perl once and run the benchmarks as one big script, or does it invoke perl for every subtest? With dynamic linking you have a bit more overhead when launching a binary, but after that, differences should be minimal.

Afaik it does invoke each interpreter for each test, but it only benchmarks the actual test subroutines.
The difference in startup time is measured in a separate test: http://ankabut.net/varia/perlbench/startup/noprog/A.txt (32.5) versus .../B.txt (43.1).
The overall average penalty with libperl.so measured by perlbench on my system is -17%. This is not minimal.

If we could have a static perl binary and a standalone perl library, that seems like the best compromise here.

OK, this should be it:
http://repos.archlinux.org/viewvc.cgi/perl/trunk/PKGBUILD?r1=51813&r2=53035
It builds and works fine here. I still have to test building an application (like collectd) that needs libperl, to make sure it works as expected alongside a static perl installation.
I'll move this to testing together with the db-4.8 rebuild.

No success: I tried my luck with collectd with
configure --enable-perl --with-libperl=/usr/lib
but it fails to find a perl interpreter.
If I do
configure --enable-perl
the interpreter is found but not the libperl :(
It looks as though a static perl binary and a dynamic libperl cannot coexist after all, at least not without a lot of tweaking...
Not sure this avenue is worth pursuing.
But one easy and clean solution would be to provide a perl-libperl package in community or AUR that provides perl.
(See attachment for a PKGBUILD).