[Numpy-discussion] CTypes: How to incorporate a library with shared library module?
Tue Feb 12 01:05:16 CST 2008
On Mon, 2008-02-11 at 23:14 -0700, Damian Eads 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
That's correct. But python extensions are not shared libraries; more
exactly: some systems make the different between libraries which are
loaded when the executable is launched (dynamic linking), and libraries
which are loaded dynamically (dynamic loading, through dlopen), possible
in the middle of the execution. All python extensions fall in the later
It happens that on Linux (and most unices I know, mac os x being an
exception), those are the same. But on mac os x (and windows), those are
different: that's why you have .so and .dylib. dlopen does not really
exist on mac os X, in the sense that it is a wrapper around the native
linker/loader tools (and dlopen is not 100 % complete: you cannot
unload/reload extensions I think on mac os X). Some of the differences
are namespace (mac os X has the notion of a namespace for libraries,
which I know nothing about; unices traditionally have a flat namespace
for libraries), etc...
More information about the Numpy-discussion