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)