dynamic library loading, missing symbols
"Martin v. Löwis"
martin at v.loewis.de
Wed Jan 10 01:50:15 EST 2007
dfj225 at gmail.com schrieb:
> However, the linker fails at runtime here because it can't
> find this symbol. The variable in question does exist in the C++ code
> that in does dlopen.
Did you verify, using nm -D, that the symbol is indeed present in
the shared object, not just in the source code?
> The reason for the complication is that I don't have control over how
> the library does dlopen() or how the code that calls dlopen was
> compiled.
What flags are given to that dlopen call?
> Is there a way to set at runtime what directories or libraries the
> linker should search for these symbols?
No. The dynamic linker doesn't search files to resolve symbols; instead,
it searches the process' memory. It first loads the referenced shared
libraries (processing the DT_NEEDED records in each one); that uses
the LD_LIBRARY_PATH. Then, symbol resolution needs to find everything
in the libraries that have already been loaded.
There are various ways to control which subset of in-memory symbols
the dynamic linker considers: the RTLD_GLOBAL/RTLD_LOCAL flags play
a role, the -Bsymbolic flag given to the static linker has an impact,
and so does the symbol visibility (hidden/internal/protected).
Regards,
Martin
More information about the Python-list
mailing list