Re: .so and .a libs, tcl, postgres = in over my head
On Mon, 6 Jul 1998, Dan Jacobowitz wrote:
> > But such a shared libperl.so could have other uses -- perl compiling
> > is easier if it exists, if I remember correctly. At the moment its
> > probably faster and easier to stick with static.
>
> Definitely easier, and faster. libperl.so is only useful on systems
> which have a large number of things linked to libperl - perl and
> mod_perl being the only two I know of at the moment.
There is one compelling reason to have a libperl.so and that is to permit
the perl binary modules to link against something. Right now (as I
understand this) 'perl' has all of the symbols that libperl.so has and
exports them so when it loads a library the library links to the symbols
in 'perl' and everything is happy.
Now when you move to the case with apache you have a problem, libperl.so
is loaded, but it doesn't load into the global scope (that is what the
patch hacks in) so when you go to load a perl module it blows up because
it can't find the symbols.
With a libperl.so all of the binary perl modules can link directly against
it and then in the apache case the RTLD_GLOBAL flag can be removed as the
dlinker will be able to properly locate the symbols.
I don't know as much about the TCL case but it is probably similer. The
things to look for is if the mod_tcl (?) shared library links to libtcl
(ldd ./mod_tcl <- the ./ is important!) and that ANY other library that is
dopen'd also explicly declares that it is linked to libtcl (ldd
/usr/lib/foo.so).
The use of RTLD_GLOBAL could cause problems (ie name collisions) in more
complex cases and it should probably be eventually removed.
Jason
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: