how to best link libperl to a shared library?
Thomas Anders
instead of directly to an application?
Problems:
- "perldoc ExtUtils::Embed" only talks about linking libperl to an
*application*
- "perl -MExtUtils::Embed -e ldopts" (recommended for applications in
the above POD) typically contains /path/to/DynaLoader.a which is a
*static* library even if Perl has been configured with -Duseshrplib
- linking static libraries when building shared libraries is considered
non-portable by libtool
Before I start discussing more details: is linking libperl to a shared
library considered supported? Are there any portable open-source
packages doing so?
+Thomas
Andy Dougherty
> What's the recommended generic way to link libperl to a *shared library*
> instead of directly to an application?
> Problems:
> - "perldoc ExtUtils::Embed" only talks about linking libperl to an
> *application*
> - "perl -MExtUtils::Embed -e ldopts" (recommended for applications in
> the above POD) typically contains /path/to/DynaLoader.a which is a
> *static* library even if Perl has been configured with -Duseshrplib
This has been changed in 5.9.5 (due out shortly, and well on the way to
what will be the new stable version, 5.10.0) so that there is no
DynaLoader.a if you build -Duseshrplib. Your problem will then probably
just magically go away.
For 5.8.x, however, you're stuck with DynaLoader.a still being needed.
As to your broader question, I don't know. I'm not aware of any generic
way, and I'm not sure that the concept is even truly portable. Others on
this list may have relevant experience.
--
Andy Dougherty doug...@lafayette.edu
Thomas Anders
> This has been changed in 5.9.5 (due out shortly, and well on the way to
> what will be the new stable version, 5.10.0) so that there is no
> DynaLoader.a if you build -Duseshrplib. Your problem will then probably
> just magically go away.
I've tried with 5.9.5-to-be and it indeed looks better. However, why
does "perl -MExtUtils::Embed -e ldopts" still list dependent libraries
(from "perl -V:perllibs") even though libperl.so has proper dependencies
built in?
perlhack# perl5.9.5 -MExtUtils::Embed -e ldopts
-Wl,-E -Wl,-rpath,/my/perl-blead/lib/5.9.5/i686-linux/CORE
-L/usr/local/lib -L/my/perl-blead/lib/5.9.5/i686-linux/CORE -lperl
-lnsl -ldl -lm -lcrypt -lutil -lc
perlhack# ldd /my/perl-blead/lib/5.9.5/i686-linux/CORE/libperl.so
linux-gate.so.1 => (0xffffe000)
libnsl.so.1 => /lib/libnsl.so.1 (0xb7e09000)
libdl.so.2 => /lib/libdl.so.2 (0xb7e05000)
libm.so.6 => /lib/libm.so.6 (0xb7ddf000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7dac000)
libutil.so.1 => /lib/libutil.so.1 (0xb7da7000)
libc.so.6 => /lib/libc.so.6 (0xb7c79000)
/lib/ld-linux.so.2 (0x80000000)
I'd argue "... -lperl" should be enough.
Then, still, this is purely academic for the problem at hand. We need to
link against users' existing Perl installations today, so we need to
deal with (the limitations of) 5.8.x and earlier anyway. Further
feedback welcome.
+Thomas
Nicholas Clark
> Andy Dougherty wrote:
> > This has been changed in 5.9.5 (due out shortly, and well on the way to
> > what will be the new stable version, 5.10.0) so that there is no
> > DynaLoader.a if you build -Duseshrplib. Your problem will then probably
> > just magically go away.
>
> I've tried with 5.9.5-to-be and it indeed looks better. However, why
> does "perl -MExtUtils::Embed -e ldopts" still list dependent libraries
> (from "perl -V:perllibs") even though libperl.so has proper dependencies
> built in?
> Then, still, this is purely academic for the problem at hand. We need to
> link against users' existing Perl installations today, so we need to
> deal with (the limitations of) 5.8.x and earlier anyway. Further
> feedback welcome.
Well, I think you're either going to have to lump it, link against
DynaLoader.a, and hope that the platform doesn't get upset. (Should be OK on
most ld.so systems except x86_64 and quite old ARM).
Or extract DynaLoader's source from the Perl distribution, ship it as part of
your source, and make sure it compiles with -FPIC (or whatever the correct
options are for a shared library, which I think Config.pm knows.
ExtUtils::MakeMaker might actually do that automatically if you try building
it outside the Perl core - the special casing to build it statically is
actually in the code in the core perl build system that calls
ExtUtils::MakeMaker.
Nicholas Clark
Thomas Anders
> Well, I think you're either going to have to lump it, link against
> DynaLoader.a, and hope that the platform doesn't get upset.
I still haven't got a clue how to reliably check this within the context
of an autoconf/libtool based build system, but I realize this may not be
the appropriate audience to ask. (But if anyone happens to know ... :-)).
> (Should be OK on most ld.so systems except x86_64 and quite old ARM).
What's wrong (exactly) with x86_64 in this regard? IIRC I've
successfully built like this on x86_64.
+Thomas
Nicholas Clark
> Nicholas Clark wrote:
> > Well, I think you're either going to have to lump it, link against
> > DynaLoader.a, and hope that the platform doesn't get upset.
>
> I still haven't got a clue how to reliably check this within the context
> of an autoconf/libtool based build system, but I realize this may not be
> the appropriate audience to ask. (But if anyone happens to know ... :-)).
I don't either.
> > (Should be OK on most ld.so systems except x86_64 and quite old ARM).
>
> What's wrong (exactly) with x86_64 in this regard? IIRC I've
> successfully built like this on x86_64.
As I understand it, it can't link code compiled without -FPIC (or whatever
the option is for position independent code) into a shared library (as they
need to be relocatable in memory). Historically a lot of code authored by
users of x86 systems doesn't realise that it's making a non-portable
assumption by assuming that it's fine to do this. (gcc, x86, glibc, and ld.so
have a lot to answer for in permitting non-portability)
Nicholas Clark