[Pythonmac-SIG] Linking against a Python extension

matthias.oberlaender@daimlerchrysler.com matthias.oberlaender at daimlerchrysler.com
Wed Dec 21 08:50:56 CET 2005


bob at redivi.com schrieb am 20.12.2005 22:25:28:

> > First question: Is it possible to link against a normally built Python
> > extension?
> >
> > More specifically, I want to pass the '.so' file of some Python 
extension
> > as an extra link argument to the 'weave.inline' function. This seems 
to
> > work quite well on Linux. But I suspect, on Mac OS X  the answer is 
'no'.
> > I just want this confirmed.
> 
> No.  That's not the right way to do it anyway, you need to make a table 
of
> pointers available as a PyCObject or similar and get at it that way. 
Look
> at how something like Numeric exports its interface.

Ok, I explain my use case in more details:
Sometimes I find it convenient to use weave's inline feature for compiling 

and linking small pieces of C code at runtime. There are a bunch of 
private C 
helper functions I reuse again and again. On OS X I have thrown them into 
a 
framework so I could let weave link against it using the _platform 
specific_ 
option pattern "-F somedir -framework mychelpers". So actually, I don't 
access anything in mychelpers directly from Python, but only indirectly 
via 
weave as an "ad hoc" wrapping tool. I think, PyCObjects are not necessary 
here.

I was wondering how one could do that in a uniform way on both, Mac and 
Linux. So I tried to let distutils build a minimal extension by only 
adding 
an initmychelpers function that calls Py_InitModule with an empty method 
list. 
On Linux I can let weave use the .so file as an additional input file to 
the 
linker. It works! Locating this file is also easy if the extension module 
is on 
the python search path: import mychelpers; mychelpers.__file__.

But following the same pattern on the Mac resulted in the error message:

ld: .../mychelpers.so is input for the dynamic link editor, is not 
relocatable 
by the static link editor again

After some hours of googling, reading and blind trying I now (hopefully) 
understand why: On OS X a Python extension is not a "shared object" (in 
the 
Linux sense) and not a dynamic library, but a (Mach-O) bundle, and a 
Mach-O 
bundle is more similar to an executable file than to an object file. In 
particular: It cannot be input to the linker again. Dead end. Period. 
Correct?

> 
> > Second question: Can I use distutils right out-of-the-box to create a
> > dynamically linked shared library on OS X?
> 
> I doubt it.  Even if you could, don't do that.  It's not portable and 
the
> search paths for dynamic libraries are relative to DYLD_LIBRARY_PATH and
> the executable, so you wouldn't be ab
> 
Ok, that's what I expected. Thank you.

-- Matthias


More information about the Pythonmac-SIG mailing list