Michael Felt added the comment:
Getting back to this summary:
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
The "Gnu" selection is what is used for "None of the above", so also for AIX -
which generally has neither ldconfig nor cc installed.
Having worked on a patch for AIX so that something that is (aka should) always
there (dump) for examining archives for dlopen() openable objects.
In another issue I have had the benefit of lots of feedback from Martin Panter
- most of which I agree with.
As this issue is about enhancement my feedback re: AIX behavior of dlopen() is
that dlopen() takes LD_LIBRARY_PATH (when LIBPATH is not defined) into account.
In general find_library() is used as: CDLL(find_library("xxx")) - as in I do
not care if the result is None or libxxx.so.y.z - just do it. However, if
find_library() and CDLL() are written so that they "find" the same library
object then it does become possible for a programmer to verify that a supported
version is what will be loaded.
The return value from find_library() should be related to it's argument - just
as dlopen() would 'react' (better, search *PATH*). If no path element ("./*" |
"../*", or "/*") then no path element should be in the return value. The case
for using path elements is because find_library() could be used to verity it's
existence before calling CDLL() - what I did not know initially, but consider
vital for proper behavior is that CDLL(NULL) just returns 'python' itself.
To underline that there are many issues that have been left unaddressed for
years (this discussion here is nearly 6 years old) I mention:
"The case of python calling find_library("uuid") - on AIX this is probably
NULL, as libuuid.so(.X) is not native to AIX - and even if it is present will
not be found via a non-existent ldconfig or cc (only thing the "Gnu" option
even considers).
IMHO: find_library should reflect dlopen() - with find_library being, as
documented.
>From the Python2.6 documentation (when introduced?)
"""The purpose of the find_library() function is to locate a library in a way
similar to what the compiler does (on platforms with several versions of a
shared library the most recent should be loaded), while the ctypes library
loaders act like when a program is run, and call the runtime loader directly.
The ctypes.util module provides a function which can help to determine the
library to load.
ctypes.util.find_library(name)
Try to find a library and return a pathname. name is the library name
without any prefix like lib, suffix like .so, .dylib or version number (this is
the form used for the posix linker option -l). If no library can be found,
returns None.
The exact functionality is system dependent."""
This pre-dates my experience with python, so if I inaccurate in assumptions -
correct me, but please be patient with me.
What I miss is a PEP on this topic. From the limited reads of other PEPs I have
read I think (rather hope) that inconsistencies in documentation could have
been caught.
While (as Martin mentioned earlier in this discussion) find_library() behaves
as "build" aka cc/gcc and CDLL follows "run-time" loader. imho, this is
inconsistent - and the inconsistency is also in that short bit of documentation:
a) """The purpose of the find_library() function is to locate a library in a
way similar to what the compiler does (on platforms with several versions of a
shared library the most recent should be loaded) (i.e., always find the latest
version)"""
and
b)"""The ctypes.util module provides a function which can help to determine the
library to load.""" IMHO: how it is expected to be used because I (i.e., the
python programmer) cannot provide additional specification to locate a specific
version - find_library() is meant to find the latest always
As the Python3.5.2 documentation is nearly verbatim - this is still the
documented condition.
So - I am very happy about Martin's (partial) comment:
maybe changing towards run-time would not be such a problem as I first thought.
CDLL() does a search, by definition. Maybe I do not care what it finds - but
the argument to it is expected to platform dependent.
The "remaining" limitation of find_library(), even with searching *PATH*
included is that it MUST also return the latest version (as a request for a
specific version may not be made, or any other "extension"). An additional
weakness is that what it "finds" must always be prefixed by "lib", while
dlopen() has not such requirement. (FYI: I ran into these 'unusual' shared
libraries while packaging sudo. While it is unlikely that python would ever
load these sudo libraries it does show that there can be shared libraries that
can accessed by not "found")
Hoping this helps the discussion - would be good to have at least a
definition/documentation change so that decisions can be made.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue9998>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
