We Keep Coding

Building graph-tool on OSX with Python 3.4

I tried to install graph-tool on Mac OSX 10.10 using homebrew. The brew build process works fine, but when I try to import graph-tool I get the error described in this question.
Another problem with homebrew is that I always builds graph-tool for python2.7 and it installs the packages in the Python 2.7 sit-packages folder. But I want to use it with Python 3.4. These are the reasons why I tried to build graph-tool from source.
The ./configure command automatically uses Python 2.7, too. So I passed it the desired Python version with ./configure PYTHON=python3.4
It then detects the correct version as well as the related paths but crash with the following error:
configure: error:
Could not link test program to Python. Maybe the
main Python library has been installed in some non-standard library
path. If so, pass it to configure, via the LDFLAGS environment
variable.
Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
======================================================================
ERROR!
You probably have to install the development version of the
Python package for your distribution. The exact name of this package varies
among them.
======================================================================
The error occurs with and without PYTHON variable set.
From the output of ./configure I can see that everything works fine except for the last line, which says:
checking consistency of all components of python development
environment... no
Whats does the above line mean and how do I properly install graph-tool on my maschine?

The error message is explaining exactly what needs to be done. Since python was installed in a non-standard path, you need to pass the flag LDFLAGS="-L/usr/non-standard-path/python/lib" pointing to the directory where the python libraries are located. This is most likely "/usr/local/lib", if you are using homebrew.

I was getting this error when I was trying to install graph-tool using outdated an autoconf / automake / pkg-config combination (installed using yum in CentOS 5.10). Installing those packages from source fixed the problem... although I'm not sure how this related to my python installation....

It worked for me by passing the variable PYTHON_EXTRA_LDFLAGS="-Wl,-stack_size,1000000 -F/usr/local/Cellar/python3/3.6.3/Frameworks -framework CoreFoundation".
In your case, it would be the path to the homebrew installation of python3.4.
The way I found out is that in the config.log, the error message shows the following:
configure:19023: checking python extra libraries
configure:19030: result: -ldl -framework CoreFoundation
configure:19037: checking python extra linking flags
configure:19044: result: -Wl,-stack_size,1000000 -framework CoreFoundation Python.framework/Versions/3.6/Python
configure:19051: checking consistency of all components of python development environment
configure:19079: gcc -o conftest -g -O2 -DNDEBUG -I/usr/local/Cellar/python3/3.6.3/Frameworks/Python.framework/Versions/3.6/include/python3.6m -F/usr/local/Cellar/python3/3.6.3/Frameworks/ -Wl,-stack_size,1000000 -framework CoreFoundation Python.framework/Versions/3.6/Python conftest.c -L/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.6/lib -lpython3.6m -ldl -framework CoreFoundation -ldl -framework CoreFoundation >&5
clang: error: no such file or directory: 'Python.framework/Versions/3.6/Python'
The error seems to be path 'Python.framework/Versions/3.6/Python', that in a homebrew installation does not exist. I search for the same path in the config.log and I found this line:
PYTHON_EXTRA_LDFLAGS="-Wl,-stack_size,1000000 -framework CoreFoundation Python.framework/Versions/3.6/Python"
So, the solution for me was to pass this variable with the right path.

Installing pysox on ubuntu via pip install, cannot resolve sox.h

I'm trying to install the pysox package using pip (easy_install throws exactly the same error) on Ubuntu 12.04.2 LTS.
$ pip install pysox
[...]
building 'pysox.sox' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c pysox/sox.c -o build/temp.linux-x86_64-2.7/pysox/sox.o
pysox/sox.c:227:17: fatal error: sox.h: No such file or directory
My system has installed:
$ dpkg --list | grep sox
ii libsox-fmt-all 14.3.2-3 All SoX format libraries
ii libsox-fmt-alsa 14.3.2-3 SoX alsa format I/O library
ii libsox-fmt-ao 14.3.2-3 SoX Libao format I/O library
ii libsox-fmt-base 14.3.2-3 Minimal set of SoX format libraries
ii libsox-fmt-ffmpeg 14.3.2-3 SoX ffmpeg format library
ii libsox-fmt-mp3 14.3.2-3 SoX MP3 format library
ii libsox-fmt-oss 14.3.2-3 SoX OSS format I/O library
ii libsox-fmt-pulse 14.3.2-3 SoX PulseAudio format I/O library
ii libsox1b 14.3.2-3 SoX library of audio effects and processing
ii sox 14.3.2-3 Swiss army knife of sound processing
as well as the libasound2-plugins and libasound2-python packages. I even pulled the SoX source and added ~/sox/src/sox.h to my PATH, all to no avail. It's true that a find does not locate a sox.h, even though my binaries all seem in order. the pysox source does not seem contain sox.h either.
The pysox offical page states "Specifically you need sox.h in your include path and libsox.so and libsox.a in your link path."
But apart from compiling everything from source, I don't see how I can have those files just from the binary packages. Is it not possible to use normal package managers for this install, do I need to compile, link & include everything myself?
How does one install pysox properly on Debian/Ubuntu?

In case it helps, I had the same issue but got errors using:
sudo apt-get install libasound2-plugins libasound2-python libsox-fmt-all libsox-dev sox
I did get it to work though by dropping the libasound requests, which no longer appear to be available.
This is what worked for me... the process, I think, was:
pip3 install sox
sudo apt-get install sox libsox-fmt-all
sudo apt-get install sox libsox-dev
pip3 install pysox
Only took me about 11 hours to work that out.

Okay, this was to be expected: forgot to install the dev package for SoX, namely libsox-dev. It wasn't obvious to me at first because the standard package is sox, and the lib packages are all prefaced with libsox-fmt (and there is very little documentation on this).
anyway, this is everything you'll need on a Debian machine to get the proper files in place for pip/easy_install to package manage your modules properly for SoX:
sudo apt-get install libasound2-plugins libasound2-python libsox-fmt-all libsox-dev sox

Setting Up PocketSphinx in Mac OS X

I am running Enthought Python 2.7 as well as default Python 2.7, Xcode 4.5.1 in Mac OS 10.8.2. I am trying to develop a speech to text converter in Python. I use Enthought Python as it allows me to record in 16000Hz, 1 Channel using pyaudio, which is needed for pocketsphinx to work.
I am trying to setup pocketsphinx using brew install pocketsphinx.
I get the following errors
Even manual installation using make and using default python results in same errors
Using brew doctor, I get
How do I successfully install pocketsphinx?
Here is my config.log
Homebrew logs pocketsphinx, sphinxbase

According to the log you have outdated version of the libsndfile installed. You have a header sndfile.h, but not sndfile.pc pkg-config file:
configure:14532: checking for SNDFILE
configure:14540: $PKG_CONFIG --exists --print-errors "sndfile"
Package sndfile was not found in the pkg-config search path.
Perhaps you should add the directory containing `sndfile.pc'
to the PKG_CONFIG_PATH environment variable
No package 'sndfile' found
configure:14543: $? = 1
configure:14558: $PKG_CONFIG --exists --print-errors "sndfile"
Package sndfile was not found in the pkg-config search path.
Perhaps you should add the directory containing `sndfile.pc'
to the PKG_CONFIG_PATH environment variable
No package 'sndfile' found
configure:14561: $? = 1
No package 'sndfile' found
configure:14589: result: no
configure:14603: checking sndfile.h usability
configure:14603: gcc -std=gnu99 -c -g -O2 -Wall -
I/Library/Frameworks/Python.framework/Versions/7.3/include/python2.7 -
I/Library/Frameworks/Python.framework/Versions/7.3/include/python2.7 conftest.c >&5
configure:14603: $? = 0
configure:14603: result: yes
To solve this problem either remove the header to not confuse the configure or install newer sndfile with pkg-config support.
Actually that should be fixed in sphinxbase as well, a bug report would be welcome.

Does Python SciPy need BLAS?

numpy.distutils.system_info.BlasNotFoundError:
Blas (http://www.netlib.org/blas/) libraries not found.
Directories to search for the libraries can be specified in the
numpy/distutils/site.cfg file (section [blas]) or by setting
the BLAS environment variable.
Which tar do I need to download off this site?
I've tried the fortrans, but I keep getting this error (after setting the environment variable obviously).

If you need to use the latest versions of SciPy rather than the packaged version, without going through the hassle of building BLAS and LAPACK, you can follow the below procedure.
Install linear algebra libraries from repository (for Ubuntu),
sudo apt-get install gfortran libopenblas-dev liblapack-dev
Then install SciPy, (after downloading the SciPy source): python setup.py install or
pip install scipy
As the case may be.

The SciPy webpage used to provide build and installation instructions, but the instructions there now rely on OS binary distributions. To build SciPy (and NumPy) on operating systems without precompiled packages of the required libraries, you must build and then statically link to the Fortran libraries BLAS and LAPACK:
mkdir -p ~/src/
cd ~/src/
wget http://www.netlib.org/blas/blas.tgz
tar xzf blas.tgz
cd BLAS-*
## NOTE: The selected Fortran compiler must be consistent for BLAS, LAPACK, NumPy, and SciPy.
## For GNU compiler on 32-bit systems:
#g77 -O2 -fno-second-underscore -c *.f # with g77
#gfortran -O2 -std=legacy -fno-second-underscore -c *.f # with gfortran
## OR for GNU compiler on 64-bit systems:
#g77 -O3 -m64 -fno-second-underscore -fPIC -c *.f # with g77
gfortran -O3 -std=legacy -m64 -fno-second-underscore -fPIC -c *.f # with gfortran
## OR for Intel compiler:
#ifort -FI -w90 -w95 -cm -O3 -unroll -c *.f
# Continue below irrespective of compiler:
ar r libfblas.a *.o
ranlib libfblas.a
rm -rf *.o
export BLAS=~/src/BLAS-*/libfblas.a
Execute only one of the five g77/gfortran/ifort commands. I have commented out all, but the gfortran which I use. The subsequent LAPACK installation requires a Fortran 90 compiler, and since both installs should use the same Fortran compiler, g77 should not be used for BLAS.
Next, you'll need to install the LAPACK stuff. The SciPy webpage's instructions helped me here as well, but I had to modify them to suit my environment:
mkdir -p ~/src
cd ~/src/
wget http://www.netlib.org/lapack/lapack.tgz
tar xzf lapack.tgz
cd lapack-*/
cp INSTALL/make.inc.gfortran make.inc # On Linux with lapack-3.2.1 or newer
make lapacklib
make clean
export LAPACK=~/src/lapack-*/liblapack.a
Update on 3-Sep-2015:
Verified some comments today (thanks to all): Before running make lapacklib edit the make.inc file and add -fPIC option to OPTS and NOOPT settings. If you are on a 64bit architecture or want to compile for one, also add -m64. It is important that BLAS and LAPACK are compiled with these options set to the same values. If you forget the -fPIC SciPy will actually give you an error about missing symbols and will recommend this switch. The specific section of make.inc looks like this in my setup:
FORTRAN = gfortran
OPTS = -O2 -frecursive -fPIC -m64
DRVOPTS = $(OPTS)
NOOPT = -O0 -frecursive -fPIC -m64
LOADER = gfortran
On old machines (e.g. RedHat 5), gfortran might be installed in an older version (e.g. 4.1.2) and does not understand option -frecursive. Simply remove it from the make.inc file in such cases.
The lapack test target of the Makefile fails in my setup because it cannot find the blas libraries. If you are thorough you can temporarily move the blas library to the specified location to test the lapack. I'm a lazy person, so I trust the devs to have it working and verify only in SciPy.

On Fedora, this works:
yum install lapack lapack-devel blas blas-devel
pip install numpy
pip install scipy
Remember to install 'lapack-devel' and 'blas-devel' in addition to 'blas' and 'lapack' otherwise you'll get the error you mentioned or the "numpy.distutils.system_info.LapackNotFoundError" error.

I guess you are talking about installation in Ubuntu. Just use:
apt-get install python-numpy python-scipy
That should take care of the BLAS libraries compiling as well. Else, compiling the BLAS libraries is very difficult.

For Windows users there is a nice binary package by Chris (warning: it's a pretty large download, 191 MB):
http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

Following the instructions given by 'cfi' works for me, although there are a few pieces they left out that you might need:
1) Your lapack directory, after unzipping, may be called lapack-X-Y (some version number), so you can just rename that to LAPACK.
cd ~/src
mv lapack-[tab] LAPACK
2) In that directory, you may need to do:
cd ~/src/LAPACK
cp lapack_LINUX.a libflapack.a

Try using
sudo apt-get install python3-scipy

Installing PIL on Snow Leopard -- NOTHING WORKS

I'm trying to install PIL on Snow Leopard, using Python 2.6.1, GCC 4.2.1, PIL 1.1.7, and have tried with both libjpeg6b and libjpeg7 -- nothing works. I've cleared out every trace of libjpeg/pil/zlib from fink, tried various compiler options, etc. and used http://jetfar.com/libjpeg-and-python-imaging-pil-on-snow-leopard/ and http:// www.brambraakman.com/blog/comments/installing_pil_in_snow_leopard_jpeg_resync_to_restart_error/ (not a link because StOv only lets me post one...)
4 bits of potentially useful information:
OTOOL does not show libjpeg as a dependency
otool -L /Library/Python/2.6/site-packages/PIL/_imaging.so
/Library/Python/2.6/site-packages/PIL/_imaging.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
I get these weird compiler messages
i686-apple-darwin10-gcc-4.2.1: -framework: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.2.1: Tcl: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.2.1: -framework: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.2.1: Tk: linker input file unused because linking not done
gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch ppc -arch x86_64 -pipe -I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/Headers -IlibImaging -I/sw/include/freetype2 -I/sw/include -I/opt/local/include -I/System/Library/Frameworks/Python.framework/Versions/2.6/include -I/usr/local/include -I/usr/include -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c Tk/tkImaging.c -o build/temp.macosx-10.6-universal-2.6/Tk/tkImaging.o -framework Tcl -framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:78,
from Tk/tkImaging.c:51:
selftest.py fails because of _imagingmath (after I used the second link given above, before it too failed due to _imaging)
Themistocles:Imaging-1.1.7 me$ python selftest.py
Traceback (most recent call last):
File "selftest.py", line 11, in <module>
from PIL import ImageMath
File "./PIL/ImageMath.py", line 19, in <module>
import _imagingmath
ImportError: No module named _imagingmath
Anything but selftest.py fails because of _imaging
>>> import _imaging
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: dlopen(/Library/Python/2.6/site-packages/PIL/_imaging.so, 2): Symbol not found: _jpeg_resync_to_restart
Referenced from: /Library/Python/2.6/site-packages/PIL/_imaging.so
Expected in: flat namespace
in /Library/Python/2.6/site-packages/PIL/_imaging.so
Please, please help! This is getting ridiculous. I'd even be happy to be able to compile PIL sans jpeg support at this point!

I recently wrote an article on how to get PIL, django, libjpeg to work nicely alongside Snow Leopard
http://appelfreelance.com/2010/06/libjpeg-pil-snow-leopard-python2-6-_jpeg_resync_to_restart/
I'll copy it in here for you too.
If you don’t have this download it first.
http://www.ijg.org/files/jpegsrc.v7.tar.gz
go into your shell environment and untar by running the following
tar -zxvf jpegsrc.v7.tar.gz
cd jpeg-7
then run
sudo make clean
sudo CC="gcc -arch i386”"./configure --enable-shared --enable-static
sudo make
sudo make install
Next get PIL and untar it
http://effbot.org/downloads/Imaging-1.1.6.tar.gz
tar -zxvf Imaging-1.1.6.tar.gz
cd Imaging-1.1.6
If you already have PIL I would recommend running
sudo rm -Rf build
to clean any existing builds, this has caused me loads of errors and gray hairs!
in your settings.py file run find JPEG_ROOT
amend it so it looks as follows
JPEG_ROOT = libinclude(“/usr/local”)
Next move onto the build
sudo python setup.py build
if libjpeg is successfully installed you should be able to run python selftest.py without any errors relating to “jpeg”
sudo python setup.py install
if all has worked successfully you should be able to enter your python interpreter by executing python in your command line and also do the following:
import PIL
import Image
import _imaging
without any errors.
Just to triple check I have a simple jpeg on my desktop.
image = Image.open(“/Users/MyName/Desktop/myimage.jpeg”)
image.save(“/Users/MyName/Desktop/test.jpeg”)
should work without errors

Download macport:
http://www.macports.org/install.php
Then use it for pil:
http://trac.macports.org/browser/trunk/dports/python/py-pil/Portfile
I also had a lot of trouble with this, but port managed.

I've always gotten several screens worth of gcc errors when trying to install PIL. At some point I got something working (perhaps via MacPorts), so now my solution is to copy it to the appropriate site-packages (e.g. inside a new virtualenv).
I just posted it here: http://blogmaker.com/PIL-1.1.6-for-MacOSX-10.5-Leopard.zip
Works for me; I have no idea whether it will work for anyone else! Feel free to contact me with suggestions. And, let me know if there's a better place I should post it. PIL is both very cool and a royal hassle; it would be nice to have a definitive place for support. There are other PIL-related issues that I never solved.