homepage

The "find_library()" function in ctypes.util doesn't look in
LD_LIBRARY_PATH on Solaris or Linux or most other UNIX variants that use
that convention. This means that find_library() doesn't find libraries
that dlopen() would, and makes development with ctypes much harder than
it should be.

Would be useful, too, to add an optional parameter to the call with a
list of directories where to search?.

You could do that, I can see how that would be useful, but I think it
might be less confusing to just use the platform's way of doing that. 
For instance, on OS X, you can set DYLD_LIBRARY_PATH environment
variable to put directories in front of the normal search path, and
DYLD_FALLBACK_LIBRARY_PATH to put directories in back of the normal
search path.

Sometimes the program knows better :). Supporting LD_LIBRARY_PATH and
friends, the incremental cost of supporting an additional parameter
seems trivial.

To be honest, I do not understand this request and the discussion.
ctypes.util.find_library(), as dcumented, is supposed to simulate what
the linker does: find the name of a shared library. For example,
it returns 'libc.so.6' when called as ctypes.util.find_library('c').
AFAIK (and I don't know very much about posix shared libs or linkers)
the linker does not pay attention to (DY)LD_LIBRARY_PATH env var.
dlopen(shared-lib-name) does use this env vars, but this behaviour is
already built into dlopen.

The question is, which linker? I think it should be ld.so, which links "on
demand", and does pay attention to LD_LIBRARY_PATH. I'm not sure what the
point of find_library() is, otherwise.
Bill
On Thu, May 29, 2008 at 11:24 AM, Thomas Heller <report@bugs.python.org>
wrote:
>
> Thomas Heller <theller@ctypes.org> added the comment:
>
> To be honest, I do not understand this request and the discussion.
> ctypes.util.find_library(), as dcumented, is supposed to simulate what
> the linker does: find the name of a shared library. For example,
> it returns 'libc.so.6' when called as ctypes.util.find_library('c').
> AFAIK (and I don't know very much about posix shared libs or linkers)
> the linker does not pay attention to (DY)LD_LIBRARY_PATH env var.
>
> dlopen(shared-lib-name) does use this env vars, but this behaviour is
> already built into dlopen.
>
> ----------
> assignee: -> theller
> nosy: +theller
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue2936>
> _______________________________________
>

> The question is, which linker? I think it should be ld.so, which links "on
> demand", and does pay attention to LD_LIBRARY_PATH. I'm not sure what the
> point of find_library() is, otherwise.
The best explanation is in the python docs:
http://docs.python.org/lib/ctypes-finding-shared-libraries.html 

Yes, I've read that explanation, but I still don't see what the point of
find_library() is. Are you trying to resolve a possibly ambiguous reference
to a shared library to the one which is used by the Python interpreter? If
that's the case (and that's what the code seems to do), how about calling it
"find_library_used_by_python", and have another function, perhaps called
"find_library", which, given a partial name like "foo", searches the
LD_LIBRARY_PATH (or, on Darwin, the DYLD_LIBRARY_PATH), if set, then the
standard system locations, the, on Darwin, the DYLD_FALLBACK_LIBRARY_PATH,
to find a library called "libfoo.so.N" (or, on Darwin, "libfoo.N.dylib")?
That would be very useful. Right now, I don't see the use case for
find_library().
Bill
On Fri, May 30, 2008 at 1:58 PM, Thomas Heller <report@bugs.python.org>
wrote:
>
> Thomas Heller <theller@ctypes.org> added the comment:
>
> > The question is, which linker? I think it should be ld.so, which links
> "on
> > demand", and does pay attention to LD_LIBRARY_PATH. I'm not sure what
> the
> > point of find_library() is, otherwise.
>
> The best explanation is in the python docs:
> http://docs.python.org/lib/ctypes-finding-shared-libraries.html
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue2936>
> _______________________________________
>

OK, I went back and read the code. What I should be using is
"ctypes.cdll.LoadLibrary("libgoodstuff.1.dylib")". Thanks -- I think you
can close this issue.
Bill
On Fri, May 30, 2008 at 1:58 PM, Thomas Heller <report@bugs.python.org>
wrote:
>
> Thomas Heller <theller@ctypes.org> added the comment:
>
> > The question is, which linker? I think it should be ld.so, which links
> "on
> > demand", and does pay attention to LD_LIBRARY_PATH. I'm not sure what
> the
> > point of find_library() is, otherwise.
>
> The best explanation is in the python docs:
> http://docs.python.org/lib/ctypes-finding-shared-libraries.html
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue2936>
> _______________________________________
>

For people who pass by, this issue has been taken on again in:
https://bugs.python.org/issue9998