| msg67170 - (view) |
Author: Bill Janssen (janssen) *  |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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 |
|
|