classification
Title: ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.0, Python 2.6, Python 2.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: theller Nosy List: janssen, jcea, nh2, schmir, theller
Priority: normal Keywords:

Created on 2008-05-21 19:35 by janssen, last changed 2017-05-13 14:58 by nh2. This issue is now closed.

Files
File name Uploaded Description Edit
unnamed janssen, 2008-05-30 01:08
unnamed janssen, 2008-05-31 18:31
unnamed janssen, 2008-05-31 18:53
Messages (10)
msg67170 - (view) Author: Bill Janssen (janssen) * (Python committer) Date: 2008-05-21 19:35
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.
msg67492 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2008-05-29 14:16
Would be useful, too, to add an optional parameter to the call with a
list of directories where to search?.
msg67500 - (view) Author: Bill Janssen (janssen) * (Python committer) Date: 2008-05-29 15:54
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.
msg67501 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2008-05-29 16:16
Sometimes the program knows better :). Supporting LD_LIBRARY_PATH and
friends, the incremental cost of supporting an additional parameter
seems trivial.
msg67505 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2008-05-29 18:24
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.
msg67516 - (view) Author: Bill Janssen (janssen) * (Python committer) Date: 2008-05-30 01:08
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>
> _______________________________________
>
msg67555 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2008-05-30 20:58
> 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
msg67584 - (view) Author: Bill Janssen (janssen) * (Python committer) Date: 2008-05-31 18:31
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>
> _______________________________________
>
msg67586 - (view) Author: Bill Janssen (janssen) * (Python committer) Date: 2008-05-31 18:53
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>
> _______________________________________
>
msg293614 - (view) Author: Niklas Hambüchen (nh2) Date: 2017-05-13 14:58
For people who pass by, this issue has been taken on again in:

https://bugs.python.org/issue9998
History
Date User Action Args
2017-05-13 14:58:04nh2setnosy: + nh2
messages: + msg293614
2008-06-02 18:43:35thellersetstatus: open -> closed
resolution: not a bug
2008-05-31 18:53:03janssensetfiles: + unnamed
messages: + msg67586
2008-05-31 18:31:47janssensetfiles: + unnamed
messages: + msg67584
2008-05-30 20:58:19thellersetmessages: + msg67555
2008-05-30 01:08:49janssensetfiles: + unnamed
messages: + msg67516
2008-05-29 18:24:22thellersetassignee: theller
messages: + msg67505
nosy: + theller
2008-05-29 16:16:01jceasetmessages: + msg67501
2008-05-29 15:54:32janssensetmessages: + msg67500
2008-05-29 14:16:03jceasetnosy: + jcea
messages: + msg67492
2008-05-28 19:02:54schmirsetnosy: + schmir
2008-05-21 19:35:19janssencreate