.. -*- rest -*- .. vim:syntax=rest .. NB! Keep this document a valid restructured document. Building and installing NumPy +++++++++++++++++++++++++++++ :Authors: Numpy Developers :Discussions to: numpy-discussion@scipy.org .. Contents:: PREREQUISITES ============= Building NumPy requires the following software installed: 1) For Python 2, Python__ 2.6.x or newer. For Python 3, Python__ 3.2.x or newer. On Debian and derivative (Ubuntu): python python-dev On Windows: the official python installer on Python__ is enough Make sure that the Python package distutils is installed before continuing. For example, in Debian GNU/Linux, distutils is included in the python-dev package. Python must also be compiled with the zlib module enabled. 2) nose__ (optional) 1.0 or later This is required for testing numpy, but not for using it. Python__ http://www.python.org nose__ http://somethingaboutorange.com/mrl/projects/nose/ Basic Installation ================== To install numpy run: python setup.py build -j 4 install --prefix $HOME/.local This will compile numpy on 4 CPUs and install it into the specified prefix. To perform an inplace build that can be run from the source folder run: python setup.py build_ext --inplace -j 4 The number of build jobs can also be specified via the environment variable NPY_NUM_BUILD_JOBS. Fortran ABI mismatch ==================== The two most popular open source fortran compilers are g77 and gfortran. Unfortunately, they are not ABI compatible, which means that concretely you should avoid mixing libraries built with one with another. In particular, if your blas/lapack/atlas is built with g77, you *must* use g77 when building numpy and scipy; on the contrary, if your atlas is built with gfortran, you *must* build numpy/scipy with gfortran. Choosing the fortran compiler ----------------------------- To build with g77: python setup.py build --fcompiler=gnu To build with gfortran: python setup.py build --fcompiler=gnu95 How to check the ABI of blas/lapack/atlas ----------------------------------------- One relatively simple and reliable way to check for the compiler used to build a library is to use ldd on the library. If libg2c.so is a dependency, this means that g77 has been used. If libgfortran.so is a dependency, gfortran has been used. If both are dependencies, this means both have been used, which is almost always a very bad idea. Building with optimized BLAS support ==================================== Ubuntu/Debian ------------- In order to build with optimized a BLAS providing development package must be installed. Options are for example: - libblas-dev reference BLAS not very optimized - libatlas-base-dev generic tuned ATLAS, it is recommended to tune it to the available hardware, see /usr/share/doc/libatlas3-base/README.Debian for instructions - libopenblas-base fast and runtime detected so no tuning required but as of version 2.11 still suffers from correctness issues on some CPUs, test your applications thoughly. The actual implementation can be exchanged also after installation via the alternatives mechanism: update-alternatives --config libblas.so.3 update-alternatives --config liblapack.so.3 Or by preloading a specific BLAS library with LD_PRELOAD=/usr/lib/atlas-base/atlas/libblas.so.3 python ... Windows 64 bits notes ===================== Note: only AMD64 is supported (IA64 is not) - AMD64 is the version most people want. Free compilers (mingw-w64) -------------------------- http://mingw-w64.sourceforge.net/ To use the free compilers (mingw-w64), you need to build your own toolchain, as the mingw project only distribute cross-compilers (cross-compilation is not supported by numpy). Since this toolchain is still being worked on, serious compiler bugs can be expected. binutil 2.19 + gcc 4.3.3 + mingw-w64 runtime gives you a working C compiler (but the C++ is broken). gcc 4.4 will hopefully be able to run natively. This is the only tested way to get a numpy with a FULL blas/lapack (scipy does not work because of C++). Carl Kleffner's mingw-w64 toolchain ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Carl Kleffner has been working on mingw-w64 / OpenBLAS support and has put together toolchains for that option. The toolchains are available at https://bitbucket.org/carlkl/mingw-w64-for-python/downloads. The site.cfg should be configured like so: [openblas] libraries = openblaspy library_dirs = /lib include_dirs = /include The libopenblaspy.dll from /bin must be copied to numpy/core before the build. For this mingw-w64 toolchain manual creation of the python import libs is necessary, i.e.: gendef python2.7.dll dlltool -D python27.dll -d python27.def -l libpython27.dll.a move libpython27.dll.a libs\libpython27.dll.a For python-2.6 up to python 3.2 use https://bitbucket.org/carlkl/mingw-w64-for-python/downloads/mingwpy_win32_vc90.tar.xz or https://bitbucket.org/carlkl/mingw-w64-for-python/downloads/mingwpy_amd64_vc90.tar.xz For python-3.3 and python-3.4 use https://bitbucket.org/carlkl/mingw-w64-for-python/downloads/mingwpy_win32_vc100.tar.xz or https://bitbucket.org/carlkl/mingw-w64-for-python/downloads/mingwpy_amd64_vc100.tar.xz MS compilers ------------ If you are familiar with MS tools, that's obviously the easiest path, and the compilers are hopefully more mature (although in my experience, they are quite fragile, and often segfault on invalid C code). The main drawback is that no fortran compiler + MS compiler combination has been tested - mingw-w64 gfortran + MS compiler does not work at all (it is unclear whether it ever will). For python 2.6, you need VS 2008. The freely available version does not contains 64 bits compilers (you also need the PSDK, v6.1). It is crucial to use the right MS compiler version. For python 2.6, you must use version 15. You can check the compiler version with cl.exe /?.