remove need for site.cfg on default
Due to the fact that I was tired of adding site.cfg to scipy and numpy when building on Fedora and Ubuntu systems as well as a scipy ticket (http://scipy.org/scipy/numpy/ticket/985), I decided to try and add default system paths to numpy.distutils. You can find out more details on this ticket: http://projects.scipy.org/scipy/scipy/ticket/817 I would like to have as many people test this as possible. So I would like everyone, who has had to build numpy/scipy with a site.cfg despite having installed all the dependencies in the system default locations, to test this. If you would please update to the numpy trunk and build numpy and scipy without your old site.cfg. Regardless of whether it works or not, I would appreciate it if you could let me know. Thanks, Jarrod
Hi Jarrod, On Wed, Jan 14, 2009 at 2:21 AM, Jarrod Millman <millman@berkeley.edu>wrote:
Due to the fact that I was tired of adding site.cfg to scipy and numpy when building on Fedora and Ubuntu systems as well as a scipy ticket (http://scipy.org/scipy/numpy/ticket/985), I decided to try and add default system paths to numpy.distutils. You can find out more details on this ticket: http://projects.scipy.org/scipy/scipy/ticket/817
I would like to have as many people test this as possible. So I would like everyone, who has had to build numpy/scipy with a site.cfg despite having installed all the dependencies in the system default locations, to test this. If you would please update to the numpy trunk and build numpy and scipy without your old site.cfg. Regardless of whether it works or not, I would appreciate it if you could let me know.
I tested on Gentoo, which does some non-standard stuff in an attempt to be able to switch between implementations. The libraries in /usr/lib are symlinks to the implementations in /usr/lib/blas/, and you can have various implementations like atlas, reference, or threaded-atlas, so I can run a program called eselect that lets me switch between the implementations. For some reason, gentoo renames the f77blas libs to simply blas. As a result, I need to make a minor change numpy/distutils/system_info.py: $ svn diff Index: numpy/distutils/system_info.py =================================================================== --- numpy/distutils/system_info.py (revision 6323) +++ numpy/distutils/system_info.py (working copy) @@ -90,7 +90,7 @@ [atlas] library_dirs = /usr/lib/3dnow:/usr/lib/3dnow/atlas # for overriding the names of the atlas libraries -atlas_libs = lapack, f77blas, cblas, atlas +atlas_libs = lapack, blas, cblas, atlas [x11] library_dirs = /usr/X11R6/lib @@ -893,7 +893,7 @@ class atlas_info(system_info): section = 'atlas' dir_env_var = 'ATLAS' - _lib_names = ['f77blas','cblas'] + _lib_names = ['blas','cblas'] if sys.platform[:7]=='freebsd': _lib_atlas = ['atlas_r'] _lib_lapack = ['alapack_r'] @@ -1000,7 +1000,7 @@ self.set_info(**info) class atlas_blas_info(atlas_info): - _lib_names = ['f77blas','cblas'] + _lib_names = ['blas','cblas'] def calc_info(self): lib_dirs = self.get_lib_dirs() On my system , the symlinks point to the threaded atlas implementation. I ran the full tests and all tests passed except the 9 known failures. In case you are interested, here is the layout on gentoo $ slocate liblapack /usr/lib64/liblapack.so.0 /usr/lib64/liblapack.a /usr/lib64/lapack/atlas/liblapack.so.0 /usr/lib64/lapack/atlas/liblapack.a /usr/lib64/lapack/atlas/liblapack.la /usr/lib64/lapack/atlas/liblapack.so /usr/lib64/lapack/atlas/liblapack.so.0.0.0 /usr/lib64/lapack/reference/liblapack.so.0 /usr/lib64/lapack/reference/liblapack.a /usr/lib64/lapack/reference/liblapack.la /usr/lib64/lapack/reference/liblapack.so /usr/lib64/lapack/reference/liblapack.so.0.0.0 /usr/lib64/liblapack.so $ slocate lib*blas: /usr/lib64/blas /usr/lib64/blas/gsl /usr/lib64/blas/gsl/cblas.pc /usr/lib64/blas/atlas /usr/lib64/blas/atlas/libcblas.so.0.0.0 /usr/lib64/blas/atlas/libcblas.la /usr/lib64/blas/atlas/libcblas.so /usr/lib64/blas/atlas/libblas.so.0 /usr/lib64/blas/atlas/libcblas.so.0 /usr/lib64/blas/atlas/libblas.la /usr/lib64/blas/atlas/libblas.so /usr/lib64/blas/atlas/cblas.pc /usr/lib64/blas/atlas/libcblas.a /usr/lib64/blas/atlas/libblas.so.0.0.0 /usr/lib64/blas/atlas/blas.pc /usr/lib64/blas/atlas/libblas.a /usr/lib64/blas/reference /usr/lib64/blas/reference/libblas.so.0 /usr/lib64/blas/reference/libblas.la /usr/lib64/blas/reference/libblas.so /usr/lib64/blas/reference/libblas.so.0.0.0 /usr/lib64/blas/reference/blas.pc /usr/lib64/blas/reference/libblas.a /usr/lib64/blas/threaded-atlas /usr/lib64/blas/threaded-atlas/libcblas.so.0.0.0 /usr/lib64/blas/threaded-atlas/libcblas.la /usr/lib64/blas/threaded-atlas/libcblas.so /usr/lib64/blas/threaded-atlas/libblas.so.0 /usr/lib64/blas/threaded-atlas/libcblas.so.0 /usr/lib64/blas/threaded-atlas/libblas.la /usr/lib64/blas/threaded-atlas/libblas.so /usr/lib64/blas/threaded-atlas/cblas.pc /usr/lib64/blas/threaded-atlas/libcblas.a /usr/lib64/blas/threaded-atlas/libblas.so.0.0.0 /usr/lib64/blas/threaded-atlas/blas.pc /usr/lib64/blas/threaded-atlas/libblas.a /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux/cblas.ph /usr/lib64/libcblas.so /usr/lib64/pkgconfig/cblas.pc /usr/lib64/pkgconfig/blas.pc /usr/lib64/libgslcblas.a /usr/lib64/libblas.so.0 /usr/lib64/libcblas.so.0 /usr/lib64/libblas.so /usr/lib64/libcblas.a
On Fri, Jan 16, 2009 at 12:18 AM, Darren Dale <dsdale24@gmail.com> wrote:
Hi Jarrod,
On Wed, Jan 14, 2009 at 2:21 AM, Jarrod Millman <millman@berkeley.edu> wrote:
Due to the fact that I was tired of adding site.cfg to scipy and numpy when building on Fedora and Ubuntu systems as well as a scipy ticket (http://scipy.org/scipy/numpy/ticket/985), I decided to try and add default system paths to numpy.distutils. You can find out more details on this ticket: http://projects.scipy.org/scipy/scipy/ticket/817
I would like to have as many people test this as possible. So I would like everyone, who has had to build numpy/scipy with a site.cfg despite having installed all the dependencies in the system default locations, to test this. If you would please update to the numpy trunk and build numpy and scipy without your old site.cfg. Regardless of whether it works or not, I would appreciate it if you could let me know.
I tested on Gentoo, which does some non-standard stuff in an attempt to be able to switch between implementations. The libraries in /usr/lib are symlinks to the implementations in /usr/lib/blas/, and you can have various implementations like atlas, reference, or threaded-atlas, so I can run a program called eselect that lets me switch between the implementations. For some reason, gentoo renames the f77blas libs to simply blas.
That really baffles me. Why do distributions think it is ok to randomly rename libraries - they certainly could handle a eselect system without renaming libraries, so that they avoid breaking the softwares depending on the libraries, David
On Thu, Jan 15, 2009 at 11:53 PM, David Cournapeau <cournape@gmail.com>wrote:
On Fri, Jan 16, 2009 at 12:18 AM, Darren Dale <dsdale24@gmail.com> wrote:
Hi Jarrod,
On Wed, Jan 14, 2009 at 2:21 AM, Jarrod Millman <millman@berkeley.edu> wrote:
Due to the fact that I was tired of adding site.cfg to scipy and numpy when building on Fedora and Ubuntu systems as well as a scipy ticket (http://scipy.org/scipy/numpy/ticket/985), I decided to try and add default system paths to numpy.distutils. You can find out more details on this ticket: http://projects.scipy.org/scipy/scipy/ticket/817
I would like to have as many people test this as possible. So I would like everyone, who has had to build numpy/scipy with a site.cfg despite having installed all the dependencies in the system default locations, to test this. If you would please update to the numpy trunk and build numpy and scipy without your old site.cfg. Regardless of whether it works or not, I would appreciate it if you could let me know.
I tested on Gentoo, which does some non-standard stuff in an attempt to be able to switch between implementations. The libraries in /usr/lib are symlinks to the implementations in /usr/lib/blas/, and you can have various implementations like atlas, reference, or threaded-atlas, so I can run a program called eselect that lets me switch between the implementations. For some reason, gentoo renames the f77blas libs to simply blas.
That really baffles me. Why do distributions think it is ok to randomly rename libraries - they certainly could handle a eselect system without renaming libraries, so that they avoid breaking the softwares depending on the libraries,
I am in complete agreement. I've raised the issue with them before and didnt make any headway. Maybe its time to try again. Darren
participants (3)
-
Darren Dale -
David Cournapeau -
Jarrod Millman