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

On Thu, Aug 22, 2013 at 2:12 PM, Ralf Gommers <ralf.gommers@gmail.com>wrote:

...

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

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

On Mon, Sep 2, 2013 at 5:46 PM, Pauli Virtanen <pav@iki.fi> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hi,

02.09.2013 18:30, David Cournapeau kirjoitti: [clip]

...

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.

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.

I see, I missed that it was more than just reverting to slower versions.

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).

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

- -- Pauli Virtanen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlIkwPQACgkQ6BQxb7O0pWBnkwCfeKj32CYYCPdEWVcYYMtq/OZM 32wAoIn9yG/HNtUeh+XwqAm2uAS9sVQ5 =CKBN -----END PGP SIGNATURE-----

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

On Wed, Sep 4, 2013 at 1:00 PM, Neal Becker <ndbecker2@gmail.com> wrote:

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

This command never worked: you need to add the -shared flag to LDFLAGS (and you may want to remove rpath to MKL if you use ATLAS). David

attached site.cfg _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion