Re: .so and .a libs, tcl, postgres = in over my head
On 7 Jul 1998, Stephen Zander wrote:
> Jason> With a libperl.so all of the binary perl modules can link
> Jason> directly against it and then in the apache case the
> Jason> RTLD_GLOBAL flag can be removed as the dlinker will be able
> Jason> to properly locate the symbols.
>
> FUD. No perl extension is at all useful without a perl interpreter.
> Therefore, in apache, mod_perl has to do all the loading of perl
> extensions. If mod_perl exists, libperl.{a,so} must also exist and
> there are no symbol issues at all.
No, this is wrong. It has to do with the way symbols are resolved. Just
because mod_perl exists and it includes all the symbols from libperl.a
does not mean that all libraries dloaded after mod_perl will find those
symbols.
The dynamic loader has a scoping mechanism, when mod_perl is loaded all of
it's symbols are placed in the mod_perl scope and that scope is not
searched by default (which is good for apaches case)
In contrast when you load perl it's symbols are placed in the global scope
and future dloads will find them.
So, the trouble is simply that perl modules require that the symbols from
libperl go in the global scope and not some specified scope (via an
explicit link to libperl.so).
This could get ruff if some random apache module defined an internal
function that collided with a function in libperl [or between any other
two modules], then you'd get random failures in apache because you have to
enable RTLD_GLOBAL for perl to work properly.
Jason
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: