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

Niklas Hambüchen added the comment: For people who pass by, this issue has been taken on again in: https://bugs.python.org/issue9998 -- nosy: +nh2 ___ Python tracker ___

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

Changes by Thomas Heller <[EMAIL PROTECTED]>: -- resolution: -> invalid status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ _

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

Bill Janssen <[EMAIL PROTECTED]> added the comment: 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 <[EMAIL PROTECTED]> wrote: > > T

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

Bill Janssen <[EMAIL PROTECTED]> 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 (an

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

Thomas Heller <[EMAIL PROTECTED]> 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: htt

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

Bill Janssen <[EMAIL PROTECTED]> 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. Bill On Thu, May 29, 2008 at 11:24 AM, Thomas Heller

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

Thomas Heller <[EMAIL PROTECTED]> 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

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

Jesús Cea Avión <[EMAIL PROTECTED]> added the comment: Sometimes the program knows better :). Supporting LD_LIBRARY_PATH and friends, the incremental cost of supporting an additional parameter seems trivial. ___ Python tracker <[EMAIL PROTECTED]>

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

Bill Janssen <[EMAIL PROTECTED]> added the comment: 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

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

Jesús Cea Avión <[EMAIL PROTECTED]> added the comment: Would be useful, too, to add an optional parameter to the call with a list of directories where to search?. -- nosy: +jcea ___ Python tracker <[EMAIL PROTECTED]>

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

Changes by Ralf Schmitt <[EMAIL PROTECTED]>: -- nosy: +schmir ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing li

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

New submission from Bill Janssen <[EMAIL PROTECTED]>: 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 develo