[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] http://bugs.python.org/issue2936 ___ ___

[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 (and

[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: Thomas

[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:

[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] http://bugs.python.org/issue2936

[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: 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

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

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

Changes by Ralf Schmitt [EMAIL PROTECTED]: -- nosy: +schmir ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2936 ___ ___ Python-bugs-list mailing list