Python support disabled on install - OS X 10.6.8
C++ class library for sound analysis, synthesis, and morphing
Brought to you by:
kfitz
Menu
▾
▴
#6 Python support disabled on install - OS X 10.6.8
Hi, I tried to install Loris so I could use the Phython module, but during the install the messages below appeared, and no Python module was installed. I'm pretty new to this, so am at a loss as to what to do next. I'd be grateful for a pointer. Thanks.
Michael
----- Language Checks -----
checking for python... /usr/local/bin/python
checking whether /usr/local/bin/python version >= 1.5... yes
checking for /usr/local/bin/python version... 2.7
checking for /usr/local/bin/python platform... darwin
checking for /usr/local/bin/python script directory... ${prefix}/lib/python2.7/site-packages
checking for /usr/local/bin/python extension module directory... ${exec_prefix}/lib/python2.7/site-packages
checking for Python.h header file... checking Python.h usability... no
checking Python.h presence... no
checking for Python.h... no
configure: WARNING: Cannot find Python headers. Python support disabled.
....
Related
The Loris module needs more than a working Python installation, it needs to build against the header files for C extensions to Python. The configure script can't find those. On OS X, they are often in your Library folder somewhere, but you seem to have another version of Python installed in /usr/local. Since it is important to use the same version of the header files as your interpreter (and your OS is awfulyl old, so the build-in Python, if there was one, might be a different version), it is probably a good idea to make sure to find the Python.h that corresponds to your install. This is a long-winded way of saying that I don't know exactly where to tell you to look for that header file, because I don't know where your Python interpreter came from. Wherever the Python developer headers are, that's the folder you need to add to your search path somehow when you configure, for example
./configure CPPFLAGS=-I/path/to/my/Python/header
Did you use a package manager to install Python? Sometimes there is a python-dev package that you have to install to get the headers. If the version of Python shipped with the OS is the same as the one in /usr/local then you can probably find the header folder in the Python framework folder and build against that. But if the two Python versions are different, things might not work (or might not even build).
Thanks, that's helpful. I had already suspected there was some version issue. I don't know if my current Python (2.7.5) is the one that shipped with OS X 10.6.8, but it's the version that's being used (i.e., "python --version" returns "Python 2.7.5"). "which python" returns "/usr/local/bin/python".
I did a locate, and figured that the necessary Python.h files might be in:
/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/Python.h
But creating a PYTHONPATH in my .profile to this directory didn't help when I ran ./configure again
I'll try using the CPPFLAGS you suggested, and see what happens.
(It is an old OS, but it was a pretty good one, and I'm running it for legacy reasons.)
Thanks again.
Michael
On 2015-11-16, at 11:38 PM, Kelly Fitz wrote:
Related
Support Requests:
#6PYTHONPATH is used by the Python interpreter to find stuff like Python modules (when you get it to build, you're going to need to check that the loris module is installed in your PYTHONPATH).
configure/make and your compiler don't know anything about PYTHONPATH. There's a number of ways to tell configure where the header is. CPPFLAGS is fast and easy. But PYTHONPATH is not for that.
Oh, I see. Ok, I'll try to compile using CPPFLAGS. Thanks.
On 2015-11-17, at 12:26 AM, Kelly Fitz wrote:
Related
Support Requests:
#6Hi again,
I was able to configure using CPPFLAGS, but when I run make I get:
Undefined symbols:
"_fftw_free", referenced from:
Loris::FourierTransform::~FourierTransform()in libloris.a(libloris_la-FourierTransform.o)
Loris::FourierTransform::~FourierTransform()in libloris.a(libloris_la-FourierTransform.o)
Loris::FourierTransform::operator=(Loris::FourierTransform const&)in libloris.a(libloris_la-FourierTransform.o)
Loris::FourierTransform::operator=(Loris::FourierTransform const&)in libloris.a(libloris_la-FourierTransform.o)
Loris::FTimpl::FTimpl(unsigned long)in libloris.a(libloris_la-FourierTransform.o)
Loris::FTimpl::FTimpl(unsigned long)in libloris.a(libloris_la-FourierTransform.o)
"_fftw_malloc", referenced from:
Loris::FTimpl::FTimpl(unsigned long)in libloris.a(libloris_la-FourierTransform.o)
Loris::FTimpl::FTimpl(unsigned long)in libloris.a(libloris_la-FourierTransform.o)
"_fftw_plan_dft_1d", referenced from:
Loris::FTimpl::FTimpl(unsigned long)in libloris.a(libloris_la-FourierTransform.o)
"_fftw_destroy_plan", referenced from:
Loris::FourierTransform::~FourierTransform()in libloris.a(libloris_la-FourierTransform.o)
Loris::FourierTransform::operator=(Loris::FourierTransform const&)in libloris.a(libloris_la-FourierTransform.o)
"_fftw_execute", referenced from:
Loris::FourierTransform::transform() in libloris.a(libloris_la-FourierTransform.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [loris-analyze] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
I assume it's because the path to fftw can't be found. I installed fftw using homebrew, which says it linked correctly. Do I need to export some path references?
Thanks.
On 2015-11-17, at 12:26 AM, Kelly Fitz wrote:
Related
Support Requests:
#6Hmmm. If configure succeeded, then either it found FFTW, or decided to build without it. Evidently, it found it, in your case. So why can't it link against it?.... I wonder if there's something funny about the way that homebrew installs it. Can you post the lines in the configure output pertaining to fftw? They are right after the line
----- Library Checks -----
Thanks for continuing to look into this. I think I found the right lines (from config.log, yes?):
configure:24013: result: ----- Library Checks -----
configure:24028: checking for library containing sin
configure:24069: gcc -o conftest -g -O2 -I/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/include/python2.7 conftest.c >&5
conftest.c:39: warning: conflicting types for built-in function 'sin'
configure:24076: $? = 0
configure:24107: result: none required
configure:24116: checking for fftw_execute in -lfftw3
configure:24151: gcc -o conftest -g -O2 -I/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/include/python2.7 conftest.c -lfftw3 >&5
configure:24158: $? = 0
configure:24179: result: yes
configure:24285: checking fftw3.h usability
configure:24302: gcc -c -g -O2 -I/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/include/python2.7 conftest.c >&5
configure:24309: $? = 0
configure:24323: result: yes
configure:24327: checking fftw3.h presence
configure:24342: gcc -E -I/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/include/python2.7 conftest.c
configure:24349: $? = 0
configure:24363: result: yes
configure:24396: checking for fftw3.h
configure:24405: result: yes
On 2015-11-22, at 9:39 PM, Kelly Fitz wrote:
Related
Support Requests:
#6I would have settled for just the shell output, but this is much better. It shows clearly that fftw library and header are found, and found to be usable, at configure time. Doesn't really tell us what's wrong when it goes to link loris-analyze (which, btw, is completely separate from the Python module, so this problem might not even be interesting, except that if the build won't complete, you can't get it to install the Python module).
Can you type
ls /usr/local/lib | grep fftw
in a shell and let know what it says? I assume that you are letting homebrew install everything in /usr/local as it usually does. Let's see what it put there. I have one more hunch.
Yes, I'm just letting homebrew do whatever it does. Here's the output of ls /usr/local/lib | grep fftw:
libfftw3.3.dylib
libfftw3.a
libfftw3.dylib
libfftw3.la
libfftw3_threads.3.dylib
libfftw3_threads.a
libfftw3_threads.dylib
libfftw3f.3.dylib
libfftw3f.a
libfftw3f.dylib
libfftw3f_threads.3.dylib
libfftw3f_threads.a
libfftw3f_threads.dylib
libfftw3l.3.dylib
libfftw3l.a
libfftw3l.dylib
libfftw3l_threads.3.dylib
libfftw3l_threads.a
libfftw3l_threads.dylib
On 2015-11-22, at 10:39 PM, Kelly Fitz wrote:
Related
Support Requests:
#6I'm stumped. The library is clearly present and usable.
Try running configure with the argument --without-fftw
Hopefully, this will get you running, I'm sure you're bored with this problem by now!
That worked. Thanks for all the help.
On 2015-11-24, at 11:02 PM, Kelly Fitz wrote:
Related
Support Requests:
#6you could also just try running configure with the argument --without-fftw
Loris can get by without it.
Closed. CNR, -no-fftw is a workaround.