Cython builds using numpy fail due to incorrectly placed headers

[bgamari@…]

Cython builds of code requiring numpy fail as cython invokes gcc with the command line,

/usr/bin/gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -pipe -O2 -fwrapv -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c photon_tools/bin_photons.c -o build/temp.macosx-10.6-x86_64-2.7/photon_tools/bin_photons.o

while the headers installed by the numpy package (e.g. arrayobject.h) are located in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy. Creating a symlink as follows works around the issue,

$ cd /opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
$ sudo ln -s ../../lib/python2.7/site-packages/numpy/core/include/numpy numpy

[bgamari@…]

Cc Me!

[skymoo (Adam Mercer)]

Isn't this a problem with the software you're trying to build? i.e. it's not using the correct location for the numpy headers...

[bgamari@…]

No, the software being built uses distutils, the recommended way to build Cython code, which should take care of these platform specific details. This means, however, that this might be a problem not in numpy but in the Cython packaging.

[skymoo (Adam Mercer)]

The problem is not with NumPy as it correctly returns the correct path for it's headers when queried:

$ python
Python 2.7.3 (default, Apr 19 2012, 22:23:11) 
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from numpy.lib.utils import get_include
>>> get_include()
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include'
>>>

I imagine the software you're building, or CPython, isn't correctly querying NumPy where it's headers are located.

[bgamari@…]

As I said previously, the package uses distutils to build the Cython code. Given that numpy correctly reports its header locations, it seems that the problem in this case is in the cython port. The "port" field of this ticket should be updated accordingly.

[mf2k (Frank Schima)]

This port is no longer maintained. See #43692.

Is this still relevant?

[david.e.pi.3.14@…]

It still relevant and the solution proposed by bgamari@… still works

[seanfarley (Sean Farley)]

Ok, so it turns out that cython did have a problem with ​ignoring include paths sent to cythonize. I just tested that ​using Extensions works. Closing this as invalid since it was an upstream bug.