On Feb 12, 2008 12:41 AM, Damian Eads <eads@soe.ucsc.edu> wrote:
Robert Kern wrote:
On Feb 12, 2008 12:14 AM, Damian Eads <eads@soe.ucsc.edu> 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
On Mon, 2008-02-11 at 22:50 -0700, Damian Eads wrote: 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
David Cournapeau wrote: 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.
Yup. It usually works on Linux because the init<modulename> bit isn't checked. On Windows, it is, and the build will fail. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco