ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH

[janssen]

BPO	2936
Nosy	@theller, @jcea, @nh2
Files	unnamed unnamed unnamed

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/theller'
closed_at = <Date 2008-06-02.18:43:35.143>
created_at = <Date 2008-05-21.19:35:19.492>
labels = ['invalid', 'type-bug', 'library']
title = "ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH"
updated_at = <Date 2017-05-13.14:58:04.078>
user = 'https://bugs.python.org/janssen'

bugs.python.org fields:

activity = <Date 2017-05-13.14:58:04.078>
actor = 'nh2'
assignee = 'theller'
closed = True
closed_date = <Date 2008-06-02.18:43:35.143>
closer = 'theller'
components = ['Library (Lib)']
creation = <Date 2008-05-21.19:35:19.492>
creator = 'janssen'
dependencies = []
files = ['10476', '10487', '10489']
hgrepos = []
issue_num = 2936
keywords = []
message_count = 10.0
messages = ['67170', '67492', '67500', '67501', '67505', '67516', '67555', '67584', '67586', '293614']
nosy_count = 5.0
nosy_names = ['theller', 'jcea', 'janssen', 'schmir', 'nh2']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue2936'
versions = ['Python 2.6', 'Python 2.5', 'Python 3.0']

[janssen]

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.

[jcea]

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

[janssen]

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.

[jcea]

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

[theller]

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.

[janssen]

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\>

---

[theller]

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

[janssen]

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\>

---

[janssen]

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\>

---

[nh2]

For people who pass by, this issue has been taken on again in:

https://bugs.python.org/issue9998