 |
 |
 |
Python Library Reference |  |
 |
 |
|
|
|
Python Library Reference | |
|
|
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.
|
|
|
Python Library Reference | |
|
|