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