ANN: Scipy 0.13.0 beta 1 release
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
Hi all, I'm happy to announce the availability of the first beta release of Scipy 0.13.0. Please try this beta and report any issues on the scipy-dev mailing list. Source tarballs and release notes can be found at https://sourceforge.net/projects/scipy/files/scipy/0.13.0b1/. Windows and OS X installers will follow later (we have a minor infrastructure issue to solve, and I'm at EuroScipy now). Cheers, Ralf
![](https://secure.gravatar.com/avatar/59bdb3784070f0a6836aca9ee03ad817.jpg?s=120&d=mm&r=g)
On Fri, Aug 30, 2013 at 7:16 PM, David Cournapeau <cournape@gmail.com>wrote:
It looks like it broke the build with MKL as well (in, surprised, ARPACK). I will investigate this further this WE
Ok, I think the commit 5935030f8cced33e433804a21bdb15572d1d38e8 is quite wrong. It conflates the issue of dealing with Accelerate brokenness and using g77 ABI. I would suggest reverting it for 0.13.0 (and re-disable single precision), as fixing this correctly may require quite some time/testing. David
![](https://secure.gravatar.com/avatar/da3a0a1942fbdc5ee9a9b8115ac5dae7.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, 02.09.2013 18:30, David Cournapeau kirjoitti: [clip]
I'm -1 on returning to the previous situation where many routines on OSX are simply broken (which was the situation previously --- "disabling single precision" left several things still broken). I'd rather just postpone the 0.13.0 release until this issue is solved properly. Can you say what exactly is wrong -- as far as I know, Accelerate on OSX simply uses g77 ABI. There were some bugs previously where it in places did things differently, but on recent OSX releases this is no longer the case? I guess you are trying to link with MKL? In that case, I would rather propose restoring the previous MKL wrappers (with trivial extensions for the missing w* symbols). - -- Pauli Virtanen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlIkwPQACgkQ6BQxb7O0pWBnkwCfeKj32CYYCPdEWVcYYMtq/OZM 32wAoIn9yG/HNtUeh+XwqAm2uAS9sVQ5 =CKBN -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/59bdb3784070f0a6836aca9ee03ad817.jpg?s=120&d=mm&r=g)
On Mon, Sep 2, 2013 at 5:46 PM, Pauli Virtanen <pav@iki.fi> wrote:
I see, I missed that it was more than just reverting to slower versions.
The pb is specific to MKL, yes, but I've found a workaround: in the case of MKL, you just need to workaround the g77 ABI of the MKL vs gfortran ABI, but the LAPACK interface is the actual LAPACK, not CLAPACK. So for MKL, you need non dummy wrappers iff the function returns a complex. A dirty patch seems to confirm that this fixes the issue, I will prepare an actual patch tomorrow, David
![](https://secure.gravatar.com/avatar/0b7d465c9e16b93623fd6926775b91eb.jpg?s=120&d=mm&r=g)
Failed building on fedora 19 x86_64 using atlas: creating build/temp.linux-x86_64-2.7/numpy/linalg creating build/temp.linux-x86_64-2.7/numpy/linalg/lapack_lite compile options: '-DATLAS_INFO="\"3.8.4\"" -I/usr/include -Inumpy/core/include - Ibuild/src.linux-x86_64-2.7/numpy/core/include/numpy -Inumpy/core/src/private - Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath - Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort - Inumpy/core/include -I/usr/include/python2.7 -c' gcc: numpy/linalg/lapack_litemodule.c gcc: numpy/linalg/lapack_lite/python_xerbla.c /usr/bin/gfortran -Wall -Wl,-rpath=/opt/intel/mkl/lib/intel64 build/temp.linux- x86_64-2.7/numpy/linalg/lapack_litemodule.o build/temp.linux- x86_64-2.7/numpy/linalg/lapack_lite/python_xerbla.o -L/usr/lib64/atlas - L/usr/lib64 -Lbuild/temp.linux-x86_64-2.7 -llapack -lptf77blas -lptcblas -latlas -lpython2.7 -lgfortran -o build/lib.linux-x86_64-2.7/numpy/linalg/lapack_lite.so /usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: error: ld returned 1 exit status /usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: error: ld returned 1 exit status Build command was: env ATLAS=/usr/lib64 FFTW=/usr/lib64 BLAS=/usr/lib64 LAPACK=/usr/lib64 CFLAGS="-mtune=native -march=native -O3" LDFLAGS="-Wl,- rpath=/opt/intel/mkl/lib/intel64" python setup.py build attached site.cfg
![](https://secure.gravatar.com/avatar/59bdb3784070f0a6836aca9ee03ad817.jpg?s=120&d=mm&r=g)
On Fri, Aug 30, 2013 at 7:16 PM, David Cournapeau <cournape@gmail.com>wrote:
It looks like it broke the build with MKL as well (in, surprised, ARPACK). I will investigate this further this WE
Ok, I think the commit 5935030f8cced33e433804a21bdb15572d1d38e8 is quite wrong. It conflates the issue of dealing with Accelerate brokenness and using g77 ABI. I would suggest reverting it for 0.13.0 (and re-disable single precision), as fixing this correctly may require quite some time/testing. David
![](https://secure.gravatar.com/avatar/da3a0a1942fbdc5ee9a9b8115ac5dae7.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, 02.09.2013 18:30, David Cournapeau kirjoitti: [clip]
I'm -1 on returning to the previous situation where many routines on OSX are simply broken (which was the situation previously --- "disabling single precision" left several things still broken). I'd rather just postpone the 0.13.0 release until this issue is solved properly. Can you say what exactly is wrong -- as far as I know, Accelerate on OSX simply uses g77 ABI. There were some bugs previously where it in places did things differently, but on recent OSX releases this is no longer the case? I guess you are trying to link with MKL? In that case, I would rather propose restoring the previous MKL wrappers (with trivial extensions for the missing w* symbols). - -- Pauli Virtanen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlIkwPQACgkQ6BQxb7O0pWBnkwCfeKj32CYYCPdEWVcYYMtq/OZM 32wAoIn9yG/HNtUeh+XwqAm2uAS9sVQ5 =CKBN -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/59bdb3784070f0a6836aca9ee03ad817.jpg?s=120&d=mm&r=g)
On Mon, Sep 2, 2013 at 5:46 PM, Pauli Virtanen <pav@iki.fi> wrote:
I see, I missed that it was more than just reverting to slower versions.
The pb is specific to MKL, yes, but I've found a workaround: in the case of MKL, you just need to workaround the g77 ABI of the MKL vs gfortran ABI, but the LAPACK interface is the actual LAPACK, not CLAPACK. So for MKL, you need non dummy wrappers iff the function returns a complex. A dirty patch seems to confirm that this fixes the issue, I will prepare an actual patch tomorrow, David
![](https://secure.gravatar.com/avatar/0b7d465c9e16b93623fd6926775b91eb.jpg?s=120&d=mm&r=g)
Failed building on fedora 19 x86_64 using atlas: creating build/temp.linux-x86_64-2.7/numpy/linalg creating build/temp.linux-x86_64-2.7/numpy/linalg/lapack_lite compile options: '-DATLAS_INFO="\"3.8.4\"" -I/usr/include -Inumpy/core/include - Ibuild/src.linux-x86_64-2.7/numpy/core/include/numpy -Inumpy/core/src/private - Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath - Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort - Inumpy/core/include -I/usr/include/python2.7 -c' gcc: numpy/linalg/lapack_litemodule.c gcc: numpy/linalg/lapack_lite/python_xerbla.c /usr/bin/gfortran -Wall -Wl,-rpath=/opt/intel/mkl/lib/intel64 build/temp.linux- x86_64-2.7/numpy/linalg/lapack_litemodule.o build/temp.linux- x86_64-2.7/numpy/linalg/lapack_lite/python_xerbla.o -L/usr/lib64/atlas - L/usr/lib64 -Lbuild/temp.linux-x86_64-2.7 -llapack -lptf77blas -lptcblas -latlas -lpython2.7 -lgfortran -o build/lib.linux-x86_64-2.7/numpy/linalg/lapack_lite.so /usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: error: ld returned 1 exit status /usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: error: ld returned 1 exit status Build command was: env ATLAS=/usr/lib64 FFTW=/usr/lib64 BLAS=/usr/lib64 LAPACK=/usr/lib64 CFLAGS="-mtune=native -march=native -O3" LDFLAGS="-Wl,- rpath=/opt/intel/mkl/lib/intel64" python setup.py build attached site.cfg
participants (4)
-
David Cournapeau
-
Neal Becker
-
Pauli Virtanen
-
Ralf Gommers