Multi-distribution Linux wheels - please test
Hi, As some of you may have seen, Robert McGibbon and Nathaniel have just guided a PEP for multi-distribution Linux wheels past the approval process over on distutils-sig: https://www.python.org/dev/peps/pep-0513/ The PEP includes a docker image on which y'all can build wheels which match the PEP: https://quay.io/repository/manylinux/manylinux Now we're at the stage where we need stress-testing of the built wheels to find any problems we hadn't thought of. I've built numpy and scipy wheels here: https://nipy.bic.berkeley.edu/manylinux/ So, if you have a Linux distribution handy, we would love to hear from you about the results of testing these guys, maybe on the lines of: pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy python -c 'import numpy; numpy.test()' python -c 'import scipy; scipy.test()' These manylinux wheels should soon be available on pypi, and soon after, installable with latest pip, so we would like to fix as many problems as possible before going live. Cheers, Matthew
Test platform: python 3.4.1 on archlinux x86_64 scipy test: OK OK (KNOWNFAIL=97, SKIP=1626) numpy tests: Failed on long double and int128 tests, and got one error: Traceback (most recent call last): File "/usr/lib/python3.5/site-packages/nose/case.py", line 198, in runTest self.test(*self.arg) File "/usr/lib/python3.5/site-packages/numpy/core/tests/test_longdouble.py", line 108, in test_fromstring_missing np.array([1])) File "/usr/lib/python3.5/site-packages/numpy/testing/utils.py", line 296, in assert_equal return assert_array_equal(actual, desired, err_msg, verbose) File "/usr/lib/python3.5/site-packages/numpy/testing/utils.py", line 787, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "/usr/lib/python3.5/site-packages/numpy/testing/utils.py", line 668, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (shapes (6,), (1,) mismatch) x: array([ 1., -1., 3., 4., 5., 6.]) y: array([1]) ---------------------------------------------------------------------- Ran 6019 tests in 28.029s FAILED (KNOWNFAIL=13, SKIP=12, errors=1, failures=18 ________________________________________ From: NumPy-Discussion <numpy-discussion-bounces@scipy.org> on behalf of Matthew Brett <matthew.brett@gmail.com> Sent: 06 February 2016 22:26 To: Discussion of Numerical Python; SciPy Developers List Subject: [Numpy-discussion] Multi-distribution Linux wheels - please test Hi, As some of you may have seen, Robert McGibbon and Nathaniel have just guided a PEP for multi-distribution Linux wheels past the approval process over on distutils-sig: https://www.python.org/dev/peps/pep-0513/ The PEP includes a docker image on which y'all can build wheels which match the PEP: https://quay.io/repository/manylinux/manylinux Now we're at the stage where we need stress-testing of the built wheels to find any problems we hadn't thought of. I've built numpy and scipy wheels here: https://nipy.bic.berkeley.edu/manylinux/ So, if you have a Linux distribution handy, we would love to hear from you about the results of testing these guys, maybe on the lines of: pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy python -c 'import numpy; numpy.test()' python -c 'import scipy; scipy.test()' These manylinux wheels should soon be available on pypi, and soon after, installable with latest pip, so we would like to fix as many problems as possible before going live. Cheers, Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sat, Feb 6, 2016 at 9:28 PM, Nadav Horesh <nadavh@visionsense.com> wrote:
Test platform: python 3.4.1 on archlinux x86_64
scipy test: OK
OK (KNOWNFAIL=97, SKIP=1626)
numpy tests: Failed on long double and int128 tests, and got one error:
Traceback (most recent call last): File "/usr/lib/python3.5/site-packages/nose/case.py", line 198, in runTest self.test(*self.arg) File "/usr/lib/python3.5/site-packages/numpy/core/tests/test_longdouble.py", line 108, in test_fromstring_missing np.array([1])) File "/usr/lib/python3.5/site-packages/numpy/testing/utils.py", line 296, in assert_equal return assert_array_equal(actual, desired, err_msg, verbose) File "/usr/lib/python3.5/site-packages/numpy/testing/utils.py", line 787, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "/usr/lib/python3.5/site-packages/numpy/testing/utils.py", line 668, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal
(shapes (6,), (1,) mismatch) x: array([ 1., -1., 3., 4., 5., 6.]) y: array([1])
---------------------------------------------------------------------- Ran 6019 tests in 28.029s
FAILED (KNOWNFAIL=13, SKIP=12, errors=1, failures=18
Great - thanks so much for doing this. Do you get a different error if you compile from source? If you compile from source, do you link to OpenBLAS? Thanks again, Matthew
The reult tests of numpy 1.10.4 installed from source: OK (KNOWNFAIL=4, SKIP=6) I think I use openblas, as it is installed instead the normal blas/cblas. Nadav, ________________________________________ From: NumPy-Discussion <numpy-discussion-bounces@scipy.org> on behalf of Nadav Horesh <nadavh@visionsense.com> Sent: 07 February 2016 07:28 To: Discussion of Numerical Python; SciPy Developers List Subject: Re: [Numpy-discussion] Multi-distribution Linux wheels - please test Test platform: python 3.4.1 on archlinux x86_64 scipy test: OK OK (KNOWNFAIL=97, SKIP=1626) numpy tests: Failed on long double and int128 tests, and got one error: Traceback (most recent call last): File "/usr/lib/python3.5/site-packages/nose/case.py", line 198, in runTest self.test(*self.arg) File "/usr/lib/python3.5/site-packages/numpy/core/tests/test_longdouble.py", line 108, in test_fromstring_missing np.array([1])) File "/usr/lib/python3.5/site-packages/numpy/testing/utils.py", line 296, in assert_equal return assert_array_equal(actual, desired, err_msg, verbose) File "/usr/lib/python3.5/site-packages/numpy/testing/utils.py", line 787, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "/usr/lib/python3.5/site-packages/numpy/testing/utils.py", line 668, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (shapes (6,), (1,) mismatch) x: array([ 1., -1., 3., 4., 5., 6.]) y: array([1]) ---------------------------------------------------------------------- Ran 6019 tests in 28.029s FAILED (KNOWNFAIL=13, SKIP=12, errors=1, failures=18 ________________________________________ From: NumPy-Discussion <numpy-discussion-bounces@scipy.org> on behalf of Matthew Brett <matthew.brett@gmail.com> Sent: 06 February 2016 22:26 To: Discussion of Numerical Python; SciPy Developers List Subject: [Numpy-discussion] Multi-distribution Linux wheels - please test Hi, As some of you may have seen, Robert McGibbon and Nathaniel have just guided a PEP for multi-distribution Linux wheels past the approval process over on distutils-sig: https://www.python.org/dev/peps/pep-0513/ The PEP includes a docker image on which y'all can build wheels which match the PEP: https://quay.io/repository/manylinux/manylinux Now we're at the stage where we need stress-testing of the built wheels to find any problems we hadn't thought of. I've built numpy and scipy wheels here: https://nipy.bic.berkeley.edu/manylinux/ So, if you have a Linux distribution handy, we would love to hear from you about the results of testing these guys, maybe on the lines of: pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy python -c 'import numpy; numpy.test()' python -c 'import scipy; scipy.test()' These manylinux wheels should soon be available on pypi, and soon after, installable with latest pip, so we would like to fix as many problems as possible before going live. Cheers, Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, On Sun, Feb 7, 2016 at 2:06 AM, Nadav Horesh <nadavh@visionsense.com> wrote:
The reult tests of numpy 1.10.4 installed from source:
OK (KNOWNFAIL=4, SKIP=6)
I think I use openblas, as it is installed instead the normal blas/cblas.
Thanks again for the further tests. What do you get for: python -c 'import numpy; print(numpy.__config__.show())' Matthew
Thank you fo reminding me, it is OK now: $ python -c 'import numpy; print(numpy.__config__.show())' lapack_opt_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] blas_mkl_info: NOT AVAILABLE openblas_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] openblas_lapack_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] blas_opt_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] None I updated openblas to the latest version (0.2.15) and it pass the tests Nadav. ________________________________________ From: NumPy-Discussion <numpy-discussion-bounces@scipy.org> on behalf of Matthew Brett <matthew.brett@gmail.com> Sent: 08 February 2016 01:33 To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] Multi-distribution Linux wheels - please test Hi, On Sun, Feb 7, 2016 at 2:06 AM, Nadav Horesh <nadavh@visionsense.com> wrote:
The reult tests of numpy 1.10.4 installed from source:
OK (KNOWNFAIL=4, SKIP=6)
I think I use openblas, as it is installed instead the normal blas/cblas.
Thanks again for the further tests. What do you get for: python -c 'import numpy; print(numpy.__config__.show())' Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sun, Feb 7, 2016 at 10:09 PM, Nadav Horesh <nadavh@visionsense.com> wrote:
Thank you fo reminding me, it is OK now: $ python -c 'import numpy; print(numpy.__config__.show())'
lapack_opt_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] blas_mkl_info: NOT AVAILABLE openblas_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] openblas_lapack_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] blas_opt_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] None
I updated openblas to the latest version (0.2.15) and it pass the tests
Oh dear - now I'm confused. So you installed the wheel, and tested it, and it gave a test failure. Then you updated openblas using pacman, and then reran the tests against the wheel numpy, and they passed? That's a bit frightening - the wheel should only see its own copy of openblas... Thans for persisting, Matthew
I have atlas-lapack-base installed via pacman (required by sagemath). Since the numpy installation insisted on openblas on /usr/local, I got the openblas source-code and installed it on /usr/local. BTW, I use 1.11b rather then 1.10.x since the 1.10 is very slow in handling recarrays. For the tests I am erasing the 1.11 installation, and installing the 1.10.4 wheel. I do verify that I have the right version before running the tests, but I am not sure if there no unnoticed side effects. Would it help if I put a side the openblas installation and rerun the test? Nadav ________________________________________ From: NumPy-Discussion <numpy-discussion-bounces@scipy.org> on behalf of Matthew Brett <matthew.brett@gmail.com> Sent: 08 February 2016 08:13 To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] Multi-distribution Linux wheels - please test On Sun, Feb 7, 2016 at 10:09 PM, Nadav Horesh <nadavh@visionsense.com> wrote:
Thank you fo reminding me, it is OK now: $ python -c 'import numpy; print(numpy.__config__.show())'
lapack_opt_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] blas_mkl_info: NOT AVAILABLE openblas_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] openblas_lapack_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] blas_opt_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] None
I updated openblas to the latest version (0.2.15) and it pass the tests
Oh dear - now I'm confused. So you installed the wheel, and tested it, and it gave a test failure. Then you updated openblas using pacman, and then reran the tests against the wheel numpy, and they passed? That's a bit frightening - the wheel should only see its own copy of openblas... Thans for persisting, Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
(This is not relevant to the main topic of the thread, but FYI I think the recarray issues are fixed in 1.10.4.) On Feb 7, 2016 11:10 PM, "Nadav Horesh" <nadavh@visionsense.com> wrote:
I have atlas-lapack-base installed via pacman (required by sagemath). Since the numpy installation insisted on openblas on /usr/local, I got the openblas source-code and installed it on /usr/local. BTW, I use 1.11b rather then 1.10.x since the 1.10 is very slow in handling recarrays. For the tests I am erasing the 1.11 installation, and installing the 1.10.4 wheel. I do verify that I have the right version before running the tests, but I am not sure if there no unnoticed side effects.
Would it help if I put a side the openblas installation and rerun the test?
Nadav ________________________________________ From: NumPy-Discussion <numpy-discussion-bounces@scipy.org> on behalf of Matthew Brett <matthew.brett@gmail.com> Sent: 08 February 2016 08:13 To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] Multi-distribution Linux wheels - please test
On Sun, Feb 7, 2016 at 10:09 PM, Nadav Horesh <nadavh@visionsense.com> wrote:
Thank you fo reminding me, it is OK now: $ python -c 'import numpy; print(numpy.__config__.show())'
lapack_opt_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] blas_mkl_info: NOT AVAILABLE openblas_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] openblas_lapack_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] blas_opt_info: library_dirs = ['/usr/local/lib'] language = c libraries = ['openblas'] define_macros = [('HAVE_CBLAS', None)] None
I updated openblas to the latest version (0.2.15) and it pass the tests
Oh dear - now I'm confused. So you installed the wheel, and tested it, and it gave a test failure. Then you updated openblas using pacman, and then reran the tests against the wheel numpy, and they passed? That's a bit frightening - the wheel should only see its own copy of openblas...
Thans for persisting,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi Nadav, On Sun, Feb 7, 2016 at 11:13 PM, Nathaniel Smith <njs@pobox.com> wrote:
(This is not relevant to the main topic of the thread, but FYI I think the recarray issues are fixed in 1.10.4.)
On Feb 7, 2016 11:10 PM, "Nadav Horesh" <nadavh@visionsense.com> wrote:
I have atlas-lapack-base installed via pacman (required by sagemath). Since the numpy installation insisted on openblas on /usr/local, I got the openblas source-code and installed it on /usr/local. BTW, I use 1.11b rather then 1.10.x since the 1.10 is very slow in handling recarrays. For the tests I am erasing the 1.11 installation, and installing the 1.10.4 wheel. I do verify that I have the right version before running the tests, but I am not sure if there no unnoticed side effects.
Would it help if I put a side the openblas installation and rerun the test?
Would you mind doing something like this, and posting the output?: virtualenv test-manylinux source test-manylinux/bin/activate pip install -f https://nipy.bic.berkeley.edu/manylinux numpy==1.10.4 nose python -c 'import numpy; numpy.test()' python -c 'import numpy; print(numpy.__config__.show())' deactivate virtualenv test-from-source source test-from-source/bin/activate pip install numpy==1.10.4 nose python -c 'import numpy; numpy.test()' python -c 'import numpy; print(numpy.__config__.show())' deactivate I'm puzzled that the wheel gives a test error when the source install does not, and my best guess was an openblas problem, but this just to make sure we have the output from the exact same numpy version, at least. Thanks again, Matthew
On Feb 7, 2016 11:49 PM, "Matthew Brett" <matthew.brett@gmail.com> wrote:
Hi Nadav,
On Sun, Feb 7, 2016 at 11:13 PM, Nathaniel Smith <njs@pobox.com> wrote:
(This is not relevant to the main topic of the thread, but FYI I think
recarray issues are fixed in 1.10.4.)
On Feb 7, 2016 11:10 PM, "Nadav Horesh" <nadavh@visionsense.com> wrote:
I have atlas-lapack-base installed via pacman (required by sagemath). Since the numpy installation insisted on openblas on /usr/local, I got
the the
openblas source-code and installed it on /usr/local. BTW, I use 1.11b rather then 1.10.x since the 1.10 is very slow in handling recarrays. For the tests I am erasing the 1.11 installation, and installing the 1.10.4 wheel. I do verify that I have the right version before running the tests, but I am not sure if there no unnoticed side effects.
Would it help if I put a side the openblas installation and rerun the test?
Would you mind doing something like this, and posting the output?:
virtualenv test-manylinux source test-manylinux/bin/activate pip install -f https://nipy.bic.berkeley.edu/manylinux numpy==1.10.4 nose python -c 'import numpy; numpy.test()' python -c 'import numpy; print(numpy.__config__.show())' deactivate
virtualenv test-from-source source test-from-source/bin/activate pip install numpy==1.10.4 nose python -c 'import numpy; numpy.test()' python -c 'import numpy; print(numpy.__config__.show())' deactivate
I'm puzzled that the wheel gives a test error when the source install does not, and my best guess was an openblas problem, but this just to make sure we have the output from the exact same numpy version, at least.
It's hard to say without seeing the full output, but AFAICT the only failures mentioned so far are in long double stuff, which shouldn't have any connection to openblas at all? -n
I found another problem by running the tests of scikit-learn: python3 -c "import numpy as np; from scipy import linalg; linalg.eigh(np.random.randn(200, 200))" Segmentation fault Note that the following works: python3 -c "import numpy as np; np.linalg.eigh(np.random.randn(200, 200))" Also note that all scipy tests pass: Ran 20180 tests in 366.163s OK (KNOWNFAIL=97, SKIP=1657) -- Olivier Grisel
Note that the above segfault was found in a VM (docker-machine virtualbox guest VM launched on a OSX host). The DYNAMIC_ARCH feature of OpenBLAS detects an Sandybridge core (using https://gist.github.com/ogrisel/ad4e547a32d0eb18b4ff). Here are the flags of the CPU visible from inside the docker container: cat /proc/cpuinfo | grep flags flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx rdrand hypervisor lahf_lm If I fix the Nehalem kernel by setting the environment variable the problem disappears: OPENBLAS_CORETYPE=Nehalem python3 -c "import numpy as np; from scipy import linalg; linalg.eigh(np.random.randn(200, 200))" So this is an issue with the architecture detection of OpenBLAS. -- Olivier
On 8 February 2016 at 16:19, Olivier Grisel <olivier.grisel@ensta.org> wrote:
OPENBLAS_CORETYPE=Nehalem python3 -c "import numpy as np; from scipy import linalg; linalg.eigh(np.random.randn(200, 200))"
So this is an issue with the architecture detection of OpenBLAS.
I am seeing the same problem on a native Linux box, with Ivy Bridge processor (i5-3317U). According to your script, both my native openblas and the one in the wheel recognises my CPU as Sandybridge, but the wheel produces a segmentation fault. Setting the architecture to Nehalem works.
On 02/08/2016 05:23 PM, Daπid wrote:
On 8 February 2016 at 16:19, Olivier Grisel <olivier.grisel@ensta.org <mailto:olivier.grisel@ensta.org>> wrote:
OPENBLAS_CORETYPE=Nehalem python3 -c "import numpy as np; from scipy import linalg; linalg.eigh(np.random.randn(200, 200))"
So this is an issue with the architecture detection of OpenBLAS.
I am seeing the same problem on a native Linux box, with Ivy Bridge processor (i5-3317U). According to your script, both my native openblas and the one in the wheel recognises my CPU as Sandybridge, but the wheel produces a segmentation fault. Setting the architecture to Nehalem works.
more likely that is a bug the kernel of openblas instead of its cpu detection. The cpuinfo of Oliver indicates its at least a sandy bridge, and ivy bridge is be sandy bridge compatible. Is an up to date version of openblas used?
Hi Julian, On Mon, Feb 8, 2016 at 8:40 AM, Julian Taylor <jtaylor.debian@googlemail.com> wrote:
On 02/08/2016 05:23 PM, Daπid wrote:
On 8 February 2016 at 16:19, Olivier Grisel <olivier.grisel@ensta.org <mailto:olivier.grisel@ensta.org>> wrote:
OPENBLAS_CORETYPE=Nehalem python3 -c "import numpy as np; from scipy import linalg; linalg.eigh(np.random.randn(200, 200))"
So this is an issue with the architecture detection of OpenBLAS.
I am seeing the same problem on a native Linux box, with Ivy Bridge processor (i5-3317U). According to your script, both my native openblas and the one in the wheel recognises my CPU as Sandybridge, but the wheel produces a segmentation fault. Setting the architecture to Nehalem works.
more likely that is a bug the kernel of openblas instead of its cpu detection. The cpuinfo of Oliver indicates its at least a sandy bridge, and ivy bridge is be sandy bridge compatible. Is an up to date version of openblas used?
I used the latest release, v0.2.15: https://github.com/matthew-brett/manylinux-builds/blob/master/build_openblas... Is there a later version that we should try? Cheers, Matthew
On 8 February 2016 at 20:25, Matthew Brett <matthew.brett@gmail.com> wrote:
I used the latest release, v0.2.15:
https://github.com/matthew-brett/manylinux-builds/blob/master/build_openblas...
Is there a later version that we should try?
Cheers,
That is the one in the Fedora repos that is working for me. How are you compiling it? Mine is compiled with GCC 5 with the options seen in the source rpm: http://koji.fedoraproject.org/koji/packageinfo?packageID=15277
I used docker to run the numpy tests on base/archlinux. I had to pacman -Sy python-pip openssl and gcc (required by one of the numpy tests): ``` Ran 5621 tests in 34.482s OK (KNOWNFAIL=4, SKIP=9) ``` Everything looks fine. -- Olivier
Do not know what happened --- all test passed, even when removed openblas (Nathaniel was right). Manylinux config: python -c 'import numpy; print(numpy.__config__.show())' blas_opt_info: define_macros = [('HAVE_CBLAS', None)] libraries = ['openblas'] language = c library_dirs = ['/usr/local/lib'] lapack_opt_info: define_macros = [('HAVE_CBLAS', None)] libraries = ['openblas'] language = c library_dirs = ['/usr/local/lib'] blas_mkl_info: NOT AVAILABLE openblas_lapack_info: define_macros = [('HAVE_CBLAS', None)] libraries = ['openblas'] language = c library_dirs = ['/usr/local/lib'] openblas_info: define_macros = [('HAVE_CBLAS', None)] libraries = ['openblas'] language = c library_dirs = ['/usr/local/lib'] None Source installtion: python -c 'import numpy; print(numpy.__config__.show())' openblas_info: library_dirs = ['/usr/local/lib'] libraries = ['openblas', 'openblas'] language = c runtime_library_dirs = ['/usr/local/lib'] define_macros = [('HAVE_CBLAS', None)] openblas_lapack_info: library_dirs = ['/usr/local/lib'] libraries = ['openblas', 'openblas'] language = c runtime_library_dirs = ['/usr/local/lib'] define_macros = [('HAVE_CBLAS', None)] lapack_opt_info: extra_compile_args = ['-g -ftree-vectorize -mtune=native -march=native -O3'] runtime_library_dirs = ['/usr/local/lib'] define_macros = [('HAVE_CBLAS', None)] libraries = ['openblas', 'openblas', 'atlas', 'f77blas', 'cblas', 'blas'] language = c library_dirs = ['/usr/local/lib', '/usr/lib'] blas_mkl_info: NOT AVAILABLE blas_opt_info: extra_compile_args = ['-g -ftree-vectorize -mtune=native -march=native -O3'] runtime_library_dirs = ['/usr/local/lib'] define_macros = [('HAVE_CBLAS', None)] libraries = ['openblas', 'openblas', 'atlas', 'f77blas', 'cblas', 'blas'] language = c library_dirs = ['/usr/local/lib', '/usr/lib'] None ________________________________________ From: NumPy-Discussion <numpy-discussion-bounces@scipy.org> on behalf of Matthew Brett <matthew.brett@gmail.com> Sent: 08 February 2016 09:48 To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] Multi-distribution Linux wheels - please test Hi Nadav, On Sun, Feb 7, 2016 at 11:13 PM, Nathaniel Smith <njs@pobox.com> wrote:
(This is not relevant to the main topic of the thread, but FYI I think the recarray issues are fixed in 1.10.4.)
On Feb 7, 2016 11:10 PM, "Nadav Horesh" <nadavh@visionsense.com> wrote:
I have atlas-lapack-base installed via pacman (required by sagemath). Since the numpy installation insisted on openblas on /usr/local, I got the openblas source-code and installed it on /usr/local. BTW, I use 1.11b rather then 1.10.x since the 1.10 is very slow in handling recarrays. For the tests I am erasing the 1.11 installation, and installing the 1.10.4 wheel. I do verify that I have the right version before running the tests, but I am not sure if there no unnoticed side effects.
Would it help if I put a side the openblas installation and rerun the test?
Would you mind doing something like this, and posting the output?: virtualenv test-manylinux source test-manylinux/bin/activate pip install -f https://nipy.bic.berkeley.edu/manylinux numpy==1.10.4 nose python -c 'import numpy; numpy.test()' python -c 'import numpy; print(numpy.__config__.show())' deactivate virtualenv test-from-source source test-from-source/bin/activate pip install numpy==1.10.4 nose python -c 'import numpy; numpy.test()' python -c 'import numpy; print(numpy.__config__.show())' deactivate I'm puzzled that the wheel gives a test error when the source install does not, and my best guess was an openblas problem, but this just to make sure we have the output from the exact same numpy version, at least. Thanks again, Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sat, Feb 6, 2016 at 9:28 PM, Nadav Horesh <nadavh@visionsense.com> wrote:
Test platform: python 3.4.1 on archlinux x86_64
scipy test: OK
OK (KNOWNFAIL=97, SKIP=1626)
numpy tests: Failed on long double and int128 tests, and got one error:
Could you post the complete output from the test suite somewhere? (Maybe gist.github.com) -n -- Nathaniel J. Smith -- https://vorpus.org
On Feb 6, 2016 12:27 PM, "Matthew Brett" <matthew.brett@gmail.com> wrote:
Hi,
As some of you may have seen, Robert McGibbon and Nathaniel have just guided a PEP for multi-distribution Linux wheels past the approval process over on distutils-sig:
https://www.python.org/dev/peps/pep-0513/
The PEP includes a docker image on which y'all can build wheels which match the PEP:
This is the wrong repository :-) It moved, and there are two now: quay.io/pypa/manylinux1_x86_64 quay.io/pypa/manylinux1_i686 -n
On 6 February 2016 at 21:26, Matthew Brett <matthew.brett@gmail.com> wrote:
pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy python -c 'import numpy; numpy.test()' python -c 'import scipy; scipy.test()'
All the tests pass on my Fedora 23 with Python 2.7, but it seems to be linking to the system openblas: numpy.show_config() lapack_opt_info: libraries = ['openblas'] library_dirs = ['/usr/local/lib'] define_macros = [('HAVE_CBLAS', None)] language = c blas_opt_info: libraries = ['openblas'] library_dirs = ['/usr/local/lib'] define_macros = [('HAVE_CBLAS', None)] language = c openblas_info: libraries = ['openblas'] library_dirs = ['/usr/local/lib'] define_macros = [('HAVE_CBLAS', None)] language = c openblas_lapack_info: libraries = ['openblas'] library_dirs = ['/usr/local/lib'] define_macros = [('HAVE_CBLAS', None)] language = c blas_mkl_info: NOT AVAILABLE I can also reproduce Ogrisel's segfault.
Hi, On Mon, Feb 8, 2016 at 3:29 AM, Daπid <davidmenhur@gmail.com> wrote:
On 6 February 2016 at 21:26, Matthew Brett <matthew.brett@gmail.com> wrote:
pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy python -c 'import numpy; numpy.test()' python -c 'import scipy; scipy.test()'
All the tests pass on my Fedora 23 with Python 2.7, but it seems to be linking to the system openblas:
numpy.show_config() lapack_opt_info: libraries = ['openblas'] library_dirs = ['/usr/local/lib'] define_macros = [('HAVE_CBLAS', None)] language = c
numpy.show_config() shows the places that numpy found the libraries at build time. In the case of the manylinux wheel builds, I put openblas at /usr/local , but the place the wheel should be loading openblas from is <numpy-install-locatin>/.libs. For example, I think you'll find that the numpy tests will still pass if you remove any openblas installation at /usr/local . Thanks for testing by the way, Matthew
numpy.show_config() shows the places that numpy found the libraries at build time. In the case of the manylinux wheel builds, I put openblas at /usr/local , but the place the wheel should be loading openblas from is <numpy-install-locatin>/.libs. For example, I think you'll find that the numpy tests will still pass if you remove any openblas installation at /usr/local .
Confirmed: I do not have openblas in that location, and tests sort of pass (see a parallel email in this thread). By the way, is there a chance you could use a more specific location --- "What does your numpy.show_config() show?" is a question we often ask when receiving bug reports; having a marker location could save us an iteration when dealing with those when your wheels are common.
On Mon, Feb 8, 2016 at 10:41 AM, Evgeni Burovski <evgeny.burovskiy@gmail.com> wrote:
numpy.show_config() shows the places that numpy found the libraries at build time. In the case of the manylinux wheel builds, I put openblas at /usr/local , but the place the wheel should be loading openblas from is <numpy-install-locatin>/.libs. For example, I think you'll find that the numpy tests will still pass if you remove any openblas installation at /usr/local .
Confirmed: I do not have openblas in that location, and tests sort of pass (see a parallel email in this thread).
By the way, is there a chance you could use a more specific location --- "What does your numpy.show_config() show?" is a question we often ask when receiving bug reports; having a marker location could save us an iteration when dealing with those when your wheels are common.
That's a good idea. Matthew
participants (7)
-
Daπid -
Evgeni Burovski -
Julian Taylor -
Matthew Brett -
Nadav Horesh -
Nathaniel Smith -
Olivier Grisel