Philip Martin schrieb:
> Daniel Rall <firstname.lastname@example.org> writes:
>> +#if DARWIN
>> + status = apr_dso_load(&dso, "libsqlite3.dylib", pool);
>> + if (dso == NULL)
>> + status = apr_dso_load(&dso, "libsqlite3.so", pool);
> If I understand this correctly you are attempting to dlopen a shared
> library that is already dynamically linked to the executable. My
> first reaction is yuck! That will only work if apr_dso_load uses the
> same search path as the linker, and I seem to recall that people have
> problems running the tests when RA/FS are loaded using apr_dso_load as
> the search path doesn't do what we want, it doesn't include the build
> tree for example.
If I'm not mistaken, Daniel doesn't actually want to load a library at
all. He's trying to determine whether the _currently loaded_ library has
a certain ability / function.
Quoting the man page of dlopen:
void *dlopen(const char *filename, int flag);
If filename is a NULL pointer, then the returned handle is for the
main program. When given to dlsym(), this handle causes a search for
a symbol in the main program, followed by all shared libraries
loaded at program startup, and then all shared libraries loaded by
dlopen() with the flag RTLD_GLOBAL.
So something along the lines of
void *lib_handle = dlopen(NULL, RTLD_LAZY);
int (*threadsafe_func)(void) = dlsym(lib_handle,
should work on systems conforming to POSIX.1-2001 (again, according to
the man page).
I have no idea whether apr_dso_load supports that interface though, so
the remaining question is, whether the behaviour is sufficiently portable.
Received on Tue Nov 27 15:03:49 2007