System: Tru64 UNIX V5.1 Patch 0002
C Compiler: Compaq C V6.3-129
C++ Compiler: Compaq C++ V6.3-002
There seems to be a problem with dlopen(), when several libraries
are "chained", i.e. dlopen opens a library, which links another
shared object etc.
In such a case, dlopen doesn't find objects defined in the library file
itself. See this example with apache web server trying to dlopen shared
modules:
Cannot load /usr/local/apache/libexec/mod_mmap_static.so into server:
dlopen: libmysqlclient.so: symbol "my_net_init" unresolved
Now, looking at libmysqlclient.so with nm:
nm /usr/local/lib/mysql/libmysqlclient.so | grep my_net_init produces:
my_net_init | 0004396007688800 | T | 0000000000000008
That, is, the symbol is defined in the library itself, yet dlopen doesn't
find it?!? Is there a workaround for this other than explicitly linking the
shared library against itself while creating it? I am just afraid, that
such linkage might cause some other, unwanted effects, like infinite
loops.
Another problem with dlopen() is, that it doesn't find global symbols
either (this happened after I recreated the above libmysqlclient.so
using -lmysqlclient on the command line):
Cannot load /usr/local/apache/libexec/mod_mmap_static.so into server:
dlopen: libmysqlclient.so: symbol "errbuff" unresolved
nm /usr/local/lib/mysql/libmysqlclient.so | grep my_net_init produces:
errbuff | 0000000000000512 | C | 0000000000000000
So, this is a global symbol. Now, creating the library with _both_
-dc (to force visibility of globals) and -l<library_itself> causes
an infinite loop (apparently, since the program using the library
hangs and eats all CPUtime).
This problem is not just with apache, but with many other software
using dlopen, such as perl. It _would_ be nice to avoid static
linkages.
ArNO
2
Received on Mon Jan 22 2001 - 11:28:25 NZDT