Martin Panter added the comment:
Thanks Pau, for some reason I didn’t pick up the dylib OS X problem last time I
looked at that link. This is a quick summary of the library names searched on
different platforms:
Windows: {name} and {name}.dll, via %PATH%
OS X: lib{name}.dylib, {name}.dylib and {name}.framework/{name}, via dyld_find()
BSD: lib{name}.* via ldconfig (choose highest ABI version) and cc
Solaris: lib{name}.so via crle, and lib{name}.* via cc
Gnu: lib{name}.* via ldconfig and cc
Already, these cases seem to be half emulating the run-time linker and half the
build-time linker. I don’t have a good answer about which is “better” (it would
depend on the use case). But since we already have a mix, maybe changing
towards run-time would not be such a problem as I first thought.
A half-cooked idea of mine is a simpler function that just accounts for common
library naming conventions on various platforms, but does not extract sonames
or spawn compilers. I think this could work with what seems to be a common use
case of passing the result directly to CDLL(), which will do the real search.
For the Windows and OS X cases, a loop might be required to attempt CDLL() with
the different possibilities.
But I agree this is straying from the topic of this bug report. Perhaps I
should accept that people want to find libraries by just the build-time name,
but that are accessible at runtime.
More related reports about find_library() vs CDLL():
Issue 19317: Search Python’s RPATH
Issue 21622: Work without DT_SONAME
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
