Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #85558 > unrolled thread

Re: building c extensions with setuptools that are not tied to python installed on build machine

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: building c extensions with setuptools that are not tied to python installed on build machine Ned Deily <nad@acm.org> - 2015-02-11 16:23 -0800

#85558 — Re: building c extensions with setuptools that are not tied to python installed on build machine

In article 
<CAJv6nDPHGinODQq1Fkh1-uBcYzq2CHag7QJxsbQ0_pHT5z8EQQ@mail.gmail.com>,
 Matthew Taylor <matt@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@acm.org

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web