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.
ctypes.util module provides a function which can help to
determine the library to load.
.dylibor version number (this is the form used for the posix linker option -l). If no library can be found, returns
The exact functionality is system dependend.
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' >>>
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
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
locate the library at runtime.
See About this document... for information on suggesting changes.