[issue2936] ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH

[Bill Janssen]

Bill Janssen <bill.janssen at gmail.com> added the comment:

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 at bugs.python.org>
wrote:

>
> Thomas Heller <theller at 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 at bugs.python.org>
> <http://bugs.python.org/issue2936>
> _______________________________________
>

Added file: http://bugs.python.org/file10487/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2936>
_______________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080531/9b1117ab/attachment.txt>