[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

dynamic mod_perl & libperl.so (was Re: .so and .a libs, tcl, postgres = in over my head)



>>>>> "Dan" == Dan Jacobowitz <drow@false.org> writes:
    Dan> My question is this - is it possible, with the correct
    Dan> arguments to dlopen(), that a modperl loaded in its own scope
    Dan> could lode future modules into that same scope?  There should
    Dan> be an obvious way to do that, I would think...to load modules
    Dan> into the loader's scope.

After my FUD remark to Jason, I did some experimenting.  I was under
the erroneous impression the dlopen hierarchies would allow the last
loaded .so to see the symbols of the .so that explicitly loaded it. No
such luck.

My apologies for the FUD remark, Jason.

I don't think, however, that even using libperl.so is going to fix
this for the case where mod_perl is a dynamic module.  Consider the
following:

z.c:

#include <dlfcn.h>

int one (void) { return 1; }

int  main (void)
{
	void *ptr;
	int (*func)(void);

	ptr = dlopen ("/tmp/libz1.so", RTLD_LAZY);
	func = (int (*)(void)) dlsym (ptr, "z1");
	return (*func)();
}

z1.c:

#include <dlfcn.h>

int two (void) { return 2; }

int z1 (void)
{
	void *ptr = dlopen ("/tmp/libz2.so", RTLD_LAZY);
	int  (*func)(void) = (int (*)(void)) dlsym (ptr, "z2");
	return (*func)();
}

z2.c:

int z2 (void) {	return two () + one (); }

Under Solaris, building z2.c as

	gcc -shared -fpic -o libz2.so z2.so -L /tmp -lz1

is sufficient to get all the symbols resolved.  Under Linux, however,
that still fails complaining

/tmp/z: error in loading shared libraries
/tmp/libz2.so: undefined symbol: one

Isn't that analogous to what would be happening with a dynamic
mod_perl.so loading a dynamic Apache::* module which then wants to
access the underlying apache symbols?

-- 
Stephen
---
all coders are created equal; that they are endowed with certain
unalienable rights, of these are beer, net connectivity, and the
pursuit of bugfixes...  - Gregory R Block


--  
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: