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
Related
I want to debug ARM application on devices like Android machine, i prefer to use gdb(ARM version) than gdb with gdbserver to debug, because there is a dashboard , a visual interface for GDB in Python.
It must cooperation with gdb(ARM version) on devices,so i need to cross compiling a ARM version of gdb with python, the command used shows below:
./configure --host=arm-linux-gnueabi --target=arm-linux-gnueabi --with-python=/usr/bin
But finally a error message appeared:
configure:8096: checking whether to use python
configure:8098: result: /usr/bin/
configure:8316: checking for python2.7
configure:8334: arm-linux-gnueabi-gcc -o conftest -g -O2 -I/usr/include/python2.7 -I/usr/include/python2.7 conftest.c -ldl -ltermcap -lm -lpthread -ldl -lutil -lm -lpython2.7 -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions >&5
In file included from /usr/include/python2.7/Python.h:8:0,
from conftest.c:50:
/usr/include/python2.7/pyconfig.h:15:52: fatal error: arm-linux-gnueabi/python2.7/pyconfig.h: No such file or directory
compilation terminated.
Then I find the line 15 in /usr/include/python2.7/pyconfig.h, as below:
# elif defined(__ARM_EABI__) && !defined(__ARM_PCS_VFP)
#include <arm-linux-gnueabi/python2.7/pyconfig.h>
Here is the point, I only have x86_64-linux-gnu/python2.7/pyconfig.h in /usr/include, how can I get the arm-linux-gnueabi/python2.7/pyconfig.h? I already apt-get install python2.7-dev.
I ran into this problem when attempting to cross-compile a python wrapper module built with SWIG, but it looks to me like it will happen to anyone cross compiling python-linked C code on a Debian system.
Apparently the Debian python-dev packages are not set up with the header files to facilitate a cross compile, but it is possible to go get them manually. I'm not sure if this is a python bug or a Debian package bug, and I haven't researched if it applies to other distros.
pyconfig.h sets preprocessor defines to tell the python source code about platform-depended things like endianness and data type sizes, so the proper pyconfig.h is definitely needed to correctly compile python source. Fortunately, the pyconfig.h file should be the only file you need to grab separately, and it is available from the Debian python-dev package for your target platform.
you can download the package file for armeabi or any other architecture from https://packages.debian.org/jessie/libpython2.7-dev and extract the include directory yourself, or you can use the following commands to download the package and copy the proper files for armeabi to /usr/local/include
wget http://security.debian.org/debian-security/pool/updates/main/p/python2.7/libpython2.7-dev_2.7.9-2+deb8u2_armel.deb
dpkg -x libpython2.7-dev_2.7.9-2_armel.deb libpython2.7-dev_2.7.9-2_armel_extracted
sudo cp -r libpython2.7-dev_2.7.9-2_armel_extracted/usr/include/arm-linux-gnueabi/ /usr/local/include/
rm -r libpython2.7-dev_2.7.9-2_armel*
Note that on some cross compilers you will have to add -I /usr/local/include to the compiler options if it does not search this location by default, but to me this is better than modifying /usr/include and risking your changes being wiped out by the OS
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.
I've gotten so many different install/build errors in trying to setup rpy2 on my Ubuntu 14.04 server in a virtual environment that I've lost track. This is the last step I have in setting up my iPython server, but I've been stuck on the rpy2 install for several days now. I've tried many different things, some of which I'm sure are conflicting with each other and making my life harder (such as the dual R version installs), but I'm giving up trying to do this without outside help.
Various things I've done:
Installed python-dev and setuptools
Installed and updated pip
Installed and updated gcc
Build and install the newest version of R from source
Build and install the development version of R (r-devel) from source using Dirk Eddelbuetel's Docker file
[sudo] pip install rpy2 with stable R and development R
build rpy2 from source with stable R and development R (with --ignore-check-rversion option set)
easy_install rpy2
pip install and source install with and without R_HOME set to stable R (current default R is the unstable development verison)
If anyone has any idea what I can do to get this working, besides starting from scratch in a clean environment, then please let me know - it will be greatly appreciated. Thank you!!
The current error that I'm getting is as follows:
(.venv)zacp#contentvalue:~/rpy2-2.6.0$ python setup.py build_ext --ignore-check-rversion install
R Under development (unstable) (2015-06-16 r68524) -- "Unsuffered Consequences"
setup.py:196: UserWarning: R did not seem to have the minimum required version number
warnings.warn("R did not seem to have the minimum required version number")
/usr/local/lib/R/bin/R CMD config --ldflags
R was not built as a library
/usr/local/lib/R/bin/R CMD config --cppflags
R was not built as a library
setup.py:211: UserWarning: No include specified
warnings.warn('No include specified')
setup.py:222: UserWarning: No libraries as -l arguments to the compiler.
warnings.warn('No libraries as -l arguments to the compiler.')
Compilation parameters for rpy2's C components:
include_dirs = []
library_dirs = []
libraries = []
extra_link_args = []
running build_ext
R Under development (unstable) (2015-06-16 r68524) -- "Unsuffered Consequences"
setup.py:77: UserWarning: R did not seem to have the minimum required version number
warnings.warn("R did not seem to have the minimum required version number")
building 'rpy2.rinterface._rinterface' extension
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DR_INTERFACE_PTRS=1 -DHAVE_POSIX_SIGJMP=1 -DRIF_HAS_RSIGHAND=1 -DCSTACK_DEFNS=1 -DHAS_READLINE=1 -I./rpy/rinterface -I/usr/local/lib/python2.7.9/include/python2.7 -c ./rpy/rinterface/_rinterface.c -o build/temp.linux-x86_64-2.7/./rpy/rinterface/_rinterface.o
In file included from /usr/local/lib/python2.7.9/include/python2.7/Python.h:8:0,
from ./rpy/rinterface/_rinterface.c:55:
/usr/local/lib/python2.7.9/include/python2.7/pyconfig.h:1182:0: warning: "_POSIX_C_SOURCE" redefined [enabled by default]
#define _POSIX_C_SOURCE 200112L
^
In file included from /usr/include/signal.h:28:0,
from ./rpy/rinterface/_rinterface.c:51:
/usr/include/features.h:230:0: note: this is the location of the previous definition
# define _POSIX_C_SOURCE 200809L
^
In file included from ./rpy/rinterface/_rinterface.c:58:0:
./rpy/rinterface/_rinterface.h:8:15: fatal error: R.h: No such file or directory
#include <R.h>
^
compilation terminated.
error: command 'gcc' failed with exit status 1
I guess the version of R that I installed with apt-get was out-of-date. R 3.0 is "probably OK" according to the documentation, and I guess I misinterpreted the warnings.
Whoops!
According to pip - Unable to Install rpy2 on Ubuntu 14.04, missing R_ext/Rallocators.h: - Ask Ubuntu, you need something more recent than R version 3.0.2, and version 3.2 was recent enough. That seems to be true e.g. for rpy2 version 2.8.5.
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.
I want to use python consistently in a variety of environments. One of those environments is cygwin. One of the components I want to use is gevent (http://www.gevent.org/intro.html). Under cygwin, I have python 2.7 running (built locally, with the one line change described here, which is required for it to build: http://www.gossamer-threads.com/lists/python/python/976956).
gevent requires libevent (http://libevent.org/).
libevent seems to build just fine under cygwin (./configure && make && make install).
However, when building gevent (pip install gevent), it fails because libevent built static libraries (such as /usr/local/lib/libevent.a) and the gevent build wants shared libraries. Thus:
gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.7.13-i686-2.7/gevent/core.o -L/usr/local/lib/python2.7/config -levent -lpython2.7 -o build/lib.cygwin-1.7.13-i686-2.7/gevent/core.dll
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -levent
Meanwhile, if I try to get gevent to link statically (CFLAGS='-static' pip install gevent), -levent still fails, along with numerous warnings about how dereferencing type-punned pointer will break strict-aliasing rules and some additional ld failures:
gevent/core.c:21835: warning: dereferencing type-punned pointer will break strict-aliasing rules
....
gevent/core.c:21836: warning: dereferencing type-punned pointer will break strict-aliasing rules
gcc -shared -Wl,--enable-auto-image-base -static build/temp.cygwin-1.7.13-i686-2.7/gevent/core.o -L/usr/local/lib/python2.7/config -levent -lpython2.7 -o build/lib.cygwin-1.7.13-i686-2.7/gevent/core.dll
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -levent
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lpython2.7
... so...
I think I need to tell libevent to build .dll instead of .a, but libevent's Makefile does not actually have a .a target, and it's not clear to me how the abstractions being used would have to change to accomplish this.
So, taking a step back: how do I install gevent under python 2.7 under cygwin?
Can you try a beta release from http://code.google.com/p/gevent/downloads/list ?
It does not require any external dependencies.