Subject: Dynamic linking of perl modules
To: None <tech-toolchain@NetBSD.ORG>
From: Martin Husemann <>
List: tech-toolchain
Date: 11/05/2000 19:21:20
While trying to make Perl work on sparc64 I noticed a problem I not fully

By default perl links its main program "perl" against a static lib "libperl.a".

This library, for example, exports a global variable "PL_op".

Perl also does some modules as *.so files, for example This is linked
via something like:

   cc -o -shared (some *.o files) libperl.a

The resulting references PL_op (nm outputs "U PL_op"), but "perl" can't
load, because "perl" does not export PL_op, therefore the dynalinker
complains about a missing symbol.

Easy to solve: perl has a config option to build agains a shared,
so now "perl" loads "" and the dynalinker will resolve the PL_op
reference from against the already loaded (not tried yet,
but that's what I hope will happen).

While this should work, we have to pay a performance penalty for it (said to
be 15% longer startup time for perl).

Anyway, from my understanding of linking this indicates a bug: if the linker
does not complain about missing symbols, the resulting binary should just
work. What I would have expected to happen is: the linker should have resolved
the PL_op references by (staticaly) linking in the necessary parts from
libperl.a. Which, of course would make the binary fail miserably, as it doesn't
expect two instances of PL_op (i.e. when using PL_op in it expects to
get the content of PL_op from the main perl executable).

The best way to solve this would be some magic to make "perl" (the 
executable) export "PL_op" and similar symbols to the runtime linker, no matter
whether they are resolved from libperl.a or the object files going into
the executable. Note: I would have guessed this would work for all global
symbols automatically - so this may just be my fault giving perl's configure
broken parameters for the linking.

Now two questions: is the runtime failure when trying to load the *.so's
that have been linked without errors a toolchain bug?

And second: what is the way to make it work for perl linked against libperl.a?


(P.S.: My understanding may be tainted from doing this kind of stuff
all the time on Win32 systems, where you have to explicitly "export" a
symbol to be available to the runtime linker and you do this for both
EXE and DLL files)