When programming in a compiled language, shared libraries are accessed when compiling/linking a program, and when the program is run.
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.
.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 dependend.
On Linux, find_library
tries to run external programs
(/sbin/ldconfig, gcc, and objdump) to find the library file. It
returns the filename of the library file. Here are sone examples:
>>> from ctypes.util import find_library >>> find_library("m") 'libm.so.6' >>> find_library("c") 'libc.so.6' >>> find_library("bz2") 'libbz2.so.1.0' >>>
On OS X, find_library
tries several predefined naming schemes and
paths to locate the library, and returns a full pathname if successfull:
>>> from ctypes.util import find_library >>> find_library("c") '/usr/lib/libc.dylib' >>> find_library("m") '/usr/lib/libm.dylib' >>> find_library("bz2") '/usr/lib/libbz2.dylib' >>> find_library("AGL") '/System/Library/Frameworks/AGL.framework/AGL' >>>
On Windows, find_library
searches along the system search path,
and returns the full pathname, but since there is no predefined naming
scheme a call like find_library("c")
will fail and return
None
.
If wrapping a shared library with ctypes
, it may be better to
determine the shared library name at development type, and hardcode
that into the wrapper module instead of using find_library
to
locate the library at runtime.
See About this document... for information on suggesting changes.