Subject: Dynamic linking of perl modules
To: None <tech-toolchain@NetBSD.ORG>
From: Martin Husemann <martin@duskware.de>
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
understand:
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 IO.so. This is linked
via something like:
cc -o IO.so -shared (some *.o files) libperl.a
The resulting IO.so references PL_op (nm outputs "U PL_op"), but "perl" can't
load IO.so, 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 libperl.so,
so now "perl" loads "libperl.so" and the dynalinker will resolve the PL_op
reference from IO.so against the already loaded libperl.so (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 IO.so 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?
Martin
(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)