[Numpy-discussion] CTypes: How to incorporate a library with shared library module?

Damian Eads eads@soe.ucsc....
Tue Feb 12 00:41:55 CST 2008


Robert Kern wrote:
> On Feb 12, 2008 12:14 AM, Damian Eads <eads@soe.ucsc.edu> wrote:
>> David Cournapeau wrote:
>>> On Mon, 2008-02-11 at 22:50 -0700, Damian Eads wrote:
>>>> Dear Lou,
>>>>
>>>> You may want to try using distutils or setuputils, which makes compiling
>>>> extensions much easier. It does the hard work of finding out which flags
>>>> are needed to compile extensions on the host platform. There are many
>>>> examples on the web on how to use distutils to build C extensions
>>>> (http://docs.python.org/ext/building.html).
>>> Unfortunately, this does not work. Distutils only knows how to build
>>> python extensions, not shared libraries. Depending on the platform, this
>>> is not the same thing, and mac os X is such a platform where both are
>>> not the same.
>>>
>>> cheers,
>>>
>>> David
>> Really? distutils generates .so files for me, which I assume are shared
>> libraries. FYI: I'm running Fedora 8 on an x86. Does distutils not
>> generate a shared library on a mac?
> 
> Python extension modules are shared libraries, yes. But they must
> follow a particular format, namely exposing a correct
> "init<modulename>" function. distutils/setuptools only maked Python
> extension modules, not arbitrary shared libraries.

Perhaps I was a bit too liberal in my use of the term "extension 
module". Several small libraries for a project at work do not define the 
standard init<modulename> function, and yet they build with distutils. I 
can load them into ctypes without any hitches. Perhaps distutils does 
not check for the presence of the init<modulename> function and required 
data structures? I'll admit I may be abusing distutils by using it for 
something for which it wasn't designed.

Damian



More information about the Numpy-discussion mailing list