On Jan 11, 3:40 am, "Ames Andreas" <[EMAIL PROTECTED]> wrote:
> Have you already checked the output of LD_DEBUG=all or sth. like that?
Yes, that is how I initially knew that my libraries were not even being
processed when the linker tried to bind the symbol.
On Jan 10, 5:01 pm, "Martin v. Löwis
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> g] On Behalf Of [EMAIL PROTECTED]
> Sent: Wednesday, January 10, 2007 8:52 PM
> Subject: Re: dynamic library loading, missing symbols
>
> I suppose this means that any subsequent lib
[EMAIL PROTECTED] schrieb:
> I suppose this means that any subsequent libraries dlopened will not
> see any of the symbols in my module?
That's correct, and intentional. Python has crashed in the past when
symbols conflicted across shared libraries.
> I guess I'll have to look through the Python
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
> 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 s
Some random notes below ...
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> g] On Behalf Of [EMAIL PROTECTED]
> Sent: Wednesday, January 10, 2007 1:26 AM
> Subject: dynamic library loading, missing symbols
>
> The reason for the complication is that I don't h
[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?
