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