dynamic library loading, missing symbols

dfj225 at gmail.com dfj225 at gmail.com
Wed Jan 10 14:51:53 EST 2007


So, I did some searching and using python -v to run my code, I was able
to see that my module was loaded by the python interpreter using
dlopen("lib", 2).

2 is the RTLD_NOW flag, meaning that RTLD_LOCAL is assumed by the
system.

I suppose this means that any subsequent libraries dlopened will not
see any of the symbols in my module?

I guess I'll have to look through the Python documentation to see if
they offer any work arounds to this problem.

~Doug

On Jan 10, 9:38 am, "dfj... at gmail.com" <dfj... at gmail.com> wrote:
> > Did you verify, using nm -D, that the symbol is indeed present in
> > the shared object, not just in the source code?Yes, the symbol is found in the shared object when using nm.
>
> > What flags are given to that dlopen call?dlopen(lib, RTLD_NOW | RTLD_GLOBAL);
>
> > 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.Ok, so if the linker is searching the process address space, then I
> suppose what really comes into play here is how the Python interpreter
> dynamically loaded my module, a module which is in turn calling code
> that does the dlopen above. If the Python interpreter is not loading
> my library as global, does that mean the linker will not find them
> when subsequent libraries are 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).Ok, any other suggestions for things to try? Since all of the dlopen
> calls happen in 3rd party code, I won't really be able to modify them.
> I will try looking into more compile time flags for the linker and see
> what I can come up with. Keep in mind that this code works when it is
> all C++. Only when I add the Boost.Python wrapper to my code and then
> import in Python do I get this symbol error.
> 
> Thank you for your help,
> ~Doug




More information about the Python-list mailing list