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, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
