コンパイルされる言語でプログラミングしている場合、共有ライブラリはプログラムを コンパイル/リンクしているときと、そのプログラムが動作しているときにアクセスされます。
ctypesライブラリローダーはプログラムが動作しているときのように振る舞い、
ランタイムローダーを直接呼び出すのに対し、find_library関数の目的は
コンパイラが行うのと似た方法でライブラリを探し出すことです
(複数のバージョンの共有ライブラリがあるプラットホームでは、
一番最近に見つかったものがロードされます)。
ctypes.utilモジュールはロードするライブラリを決めるのに
役立つ関数を提供します。
.so、.dylibのような接尾辞、
あるいは、バージョン番号が何も付いていないライブラリの名前です
(これは posix リンカのオプション-l)に使われている形式です)。
もしライブラリが見つからなければ、Noneを返します。
厳密な機能はシステムに依存します。
Linuxでは、find_libraryはライブラリファイルを見つけるために
外部プログラム (/sbin/ldcon?g、gccおよびobjdump)を実行しようとします。
ライブラリファイルのファイル名を返します。いくつか例があります:
>>> 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'
>>>
OS Xでは、find_libraryはライブラリの位置を探すために、
予め定義された複数の命名方法とパスを試し、成功すればフルパスを返します:
>>> 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'
>>>
Windows では、find_libraryはシステムの探索パスに沿って探し、
フルパスを返します。しかし、予め定義された命名方法がないため、
find_library("c")のような呼び出しは失敗し、
Noneを返します。
もしctypesを使って共有ライブラリをラップするなら、
実行時にライブラリを探すためにfind_libraryを使う代わりに、
開発時に共有ライブラリ名をを決めて、ラッパーモジュールに
ハードコードした方が良いかもしれません。
ご意見やご指摘をお寄せになりたい方は、 このドキュメントについて... をご覧ください。