building c extensions with setuptools that are not tied to python installed on build machine
Ned Deily
nad at acm.org
Wed Feb 11 19:23:05 EST 2015
In article
<CAJv6nDPHGinODQq1Fkh1-uBcYzq2CHag7QJxsbQ0_pHT5z8EQQ at mail.gmail.com>,
Matthew Taylor <matt at numenta.org> wrote:
> Does this make sense to anyone? I'm still a little new to Python in
> general (especially binary packaging), and it seems like this would be
> a common problem for any projects with C extensions that need broad
> binary distribution. Does anyone have any suggestions? Please take a
> look at our setup.py file [4] and tell me if we're doing something
> egregiously wrong.
Just taking a quick look at your setup.py there shows a quite
complicated build, including SWIG. One suggestion: keep in mind that
it's normal on OS X for the absolute path of shared libraries and
frameworks to be embedded in the linked binaries, including the C (or
C++) extension module bundles (.so files) built for Python packages. If
any of the .so files or any other binary artifacts (executables, shared
libraries) created by your package are linked to the Python
interpreter's shared library, that may be why you are getting a mixture
of Python instances. One way to check for this is to use:
otool -L *.so *.dylib
on all of the directories containing linked binaries in your project and
check for paths like:
/System/Library/Frameworks/Python.framework
That would be a link to the Apple-supplied system Python.
A link to /Library/Frameworks/Python.framework or some other path would
be to a third-party Python like from python.org or Homebrew.
Due to differences in how the various Pythons are built and depending on
what the C or C++ code is doing, it may not be possible to have one
binary wheel that works with different Python instances of the same
version. For many simple projects, it does work.
You *could* also ask on the PythonMac SIG list.
https://mail.python.org/mailman/listinfo/pythonmac-sig
--
Ned Deily,
nad at acm.org
More information about the Python-list
mailing list