Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#10971 - [perl] libperl missing

Attached to Project: Arch Linux
Opened by Daniel D. (danield) - Monday, 21 July 2008, 20:43 GMT
Last edited by Francois Charette (Firmicus) - Friday, 02 October 2009, 06:48 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Kevin Piche (kpiche)
Francois Charette (Firmicus)
Architecture All
Severity Medium
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


I'm not into the details of packaging perl, but as far as I can tell, libperl is missing from the perl package.

I'd need it for collectd's perl plugin feature.

Additional info:
* package version(s)
* config and/or log files etc.

Steps to reproduce:
This task depends upon

Closed by  Francois Charette (Firmicus)
Friday, 02 October 2009, 06:48 GMT
Reason for closing:  Implemented
Additional comments about closing:  This is implemented in the perl 5.10.1 currently in testing.
Comment by Jan de Groot (JGC) - Tuesday, 22 July 2008, 09:59 GMT
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* in /usr/lib/ btw.
Comment by Gavin Bisesi (Daenyth) - Saturday, 21 March 2009, 14:13 GMT
What's the status on this? Is it even needed?
Comment by Daniel D. (danieldanner) - Saturday, 21 March 2009, 14:23 GMT
Yes, it's still needed to use collectd's perl plugin feature. :)
Comment by Francois Charette (Firmicus) - Friday, 11 September 2009, 11:45 GMT
According to the INSTALL documentation, there is a significant performance penalty associated with building a
See (section "Building a shared Perl library").
So -1 from me.
Comment by Jan de Groot (JGC) - Friday, 11 September 2009, 12:21 GMT
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.
Comment by Francois Charette (Firmicus) - Friday, 11 September 2009, 14:25 GMT
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.
Comment by Francois Charette (Firmicus) - Friday, 11 September 2009, 21:44 GMT
OK, I have used perlbench ( to benchmark static perl vs
I have put the results at
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 while keeping a statically compiled perl binary?
This should be manageable using split packages, but one should then find a way to hide from perl while making it available to external applications. Just thinking aloud. Perhaps this is not really doable.
Comment by Jan de Groot (JGC) - Friday, 11 September 2009, 21:53 GMT
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.
Comment by Francois Charette (Firmicus) - Saturday, 12 September 2009, 08:06 GMT
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: (32.5) versus .../B.txt (43.1).
The overall average penalty with measured by perlbench on my system is -17%. This is not minimal.
Comment by Dan McGee (toofishes) - Sunday, 20 September 2009, 15:44 GMT
If we could have a static perl binary and a standalone perl library, that seems like the best compromise here.
Comment by Francois Charette (Firmicus) - Friday, 25 September 2009, 10:07 GMT
OK, this should be it:
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.
Comment by Francois Charette (Firmicus) - Friday, 25 September 2009, 13:56 GMT
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).