trouble building numpy 1.6.1 on Scientific Linux 5
I'm trying to build numpy 1.6.1 on Scientific Linux 5 but the unit tests claim the wrong version of fortran was used. I thought I knew how to avoid that, but it's not working. I don't have atlas (this needs to run on a lot of similar-but-not-identical machines). I believe blas and lapack were built against gfortran: -bash-3.2$ ldd /usr/lib64/libblas.so linux-vdso.so.1 => (0x00007fff4bffd000) libm.so.6 => /lib64/libm.so.6 (0x00002ab26a0c8000) libgfortran.so.1 => /usr/lib64/libgfortran.so.1 (0x00002ab26a34c000) libc.so.6 => /lib64/libc.so.6 (0x00002ab26a5e3000) /lib64/ld-linux-x86-64.so.2 (0x0000003b2ba00000) -bash-3.2$ ldd /usr/lib64/liblapack.so linux-vdso.so.1 => (0x00007fffe97fd000) libblas.so.3 => /usr/lib64/libblas.so.3 (0x00002b6438d75000) libm.so.6 => /lib64/libm.so.6 (0x00002b6438fca000) libgfortran.so.1 => /usr/lib64/libgfortran.so.1 (0x00002b643924d000) libc.so.6 => /lib64/libc.so.6 (0x00002b64394e4000) /lib64/ld-linux-x86-64.so.2 (0x0000003b2ba00000) The sysadmins have provided a gcc 4.4.0 compiler that I access using symlinks on my $PATH: -bash-3.2$ which gcc g++ gfortran ~/local/bin/gcc ~/local/bin/g++ ~/local/bin/gfortran -bash-3.2$ ls -l ~/local/bin lrwxrwxrwx 1 rowen astro 14 Oct 28 2010 g++ -> /usr/bin/g++44 lrwxrwxrwx 1 rowen astro 14 Oct 28 2010 gcc -> /usr/bin/gcc44 lrwxrwxrwx 1 rowen astro 19 Dec 5 16:40 gfortran -> /usr/bin/gfortran44 -bash-3.2$ gfortran --version GNU Fortran (GCC) 4.4.0 20090514 (Red Hat 4.4.0-6) Copyright (C) 2009 Free Software Foundation, Inc. For this log I used a home-bulit python 2.6.5 that is widely used. However, I've tried it with other builds of python that are on our system, as well, with no better success (including a Python 2.7.2). -bash-3.2$ which python /astro/apps/pkg/python64/bin/python -bash-3.2$ python Python 2.6.5 (r265:79063, Aug 4 2010, 11:27:53) [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2 Type "help", "copyright", "credits" or "license" for more information. numpy seems to see gfortran when it builds: -bash-3.2$ python setup.py build --fcompiler=gnu95 Running from numpy source directory.non-existing path in 'numpy/distutils': 'site.cfg' F2PY Version 2 blas_opt_info: blas_mkl_info: ... NOT AVAILABLE atlas_blas_threads_info: ... NOT AVAILABLE atlas_blas_info: ... NOT AVAILABLE blas_info: ... FOUND: libraries = ['blas'] library_dirs = ['/usr/lib64'] language = f77 FOUND: libraries = ['blas'] library_dirs = ['/usr/lib64'] define_macros = [('NO_ATLAS_INFO', 1)] language = f77 lapack_opt_info: lapack_mkl_info: mkl_info: ... NOT AVAILABLE NOT AVAILABLE atlas_threads_info: ... NOT AVAILABLE atlas_info: ... NOT AVAILABLE /astro/users/rowen/build/numpy-1.6.1/numpy/distutils/system_info.py:1330: UserWarning: Atlas (http://math-atlas.sourceforge.net/) libraries not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [atlas]) or by setting the ATLAS environment variable. warnings.warn(AtlasNotFoundError.__doc__) lapack_info: libraries lapack not found in /astro/apps/lsst_w12_sl5/Linux64/external/python/2.7.2+2/lib ... FOUND: libraries = ['lapack'] library_dirs = ['/usr/lib64'] language = f77 FOUND: libraries = ['lapack', 'blas'] library_dirs = ['/usr/lib64'] define_macros = [('NO_ATLAS_INFO', 1)] language = f77 running build running config_cc unifing config_cc, config, build_clib, build_ext, build commands --compiler options running config_fc unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options running build_src build_src building py_modules sources creating build creating build/src.linux-x86_64-2.7 creating build/src.linux-x86_64-2.7/numpy creating build/src.linux-x86_64-2.7/numpy/distutils building library "npymath" sources customize Gnu95FCompiler Found executable /astro/users/rowen/local/bin/gfortran # I install it in an out-of-the-way location just so I can test it -bash-3.2$ python setup.py install --home=~/local ... -bash-3.2$ cd -bash-3.2$ python
import numpy numpy.__path__ ['/astro/users/rowen/local/lib/python/numpy'] numpy.test() Running unit tests for numpy NumPy version 1.6.1 NumPy is installed in /astro/users/rowen/local/lib/python/numpy Python version 2.6.5 (r265:79063, Aug 4 2010, 11:27:53) [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] nose version 0.11.4 .... ====================================================================== FAIL: test_lapack (test_build.TestF77Mismatch)
Traceback (most recent call last): File "/astro/users/rowen/local/lib/python/numpy/testing/decorators.py", line 146, in skipper_func return f(*args, **kwargs) File "/astro/users/rowen/local/lib/python/numpy/linalg/tests/test_build.py", line 50, in test_lapack information.""") AssertionError: Both g77 and gfortran runtimes linked in lapack_lite ! This is likely to cause random crashes and wrong results. See numpy INSTALL.txt for more information. ---------------------------------------------------------------------- Ran 3533 tests in 13.400s Any suggestions on how to fix this? -- Russell
On Fri, Dec 9, 2011 at 8:02 PM, Russell E. Owen <rowen@uw.edu> wrote:
I'm trying to build numpy 1.6.1 on Scientific Linux 5 but the unit tests claim the wrong version of fortran was used. I thought I knew how to avoid that, but it's not working.
I don't have atlas (this needs to run on a lot of similar-but-not-identical machines). I believe blas and lapack were built against gfortran: -bash-3.2$ ldd /usr/lib64/libblas.so linux-vdso.so.1 => (0x00007fff4bffd000) libm.so.6 => /lib64/libm.so.6 (0x00002ab26a0c8000) libgfortran.so.1 => /usr/lib64/libgfortran.so.1 (0x00002ab26a34c000) libc.so.6 => /lib64/libc.so.6 (0x00002ab26a5e3000) /lib64/ld-linux-x86-64.so.2 (0x0000003b2ba00000) -bash-3.2$ ldd /usr/lib64/liblapack.so linux-vdso.so.1 => (0x00007fffe97fd000) libblas.so.3 => /usr/lib64/libblas.so.3 (0x00002b6438d75000) libm.so.6 => /lib64/libm.so.6 (0x00002b6438fca000) libgfortran.so.1 => /usr/lib64/libgfortran.so.1 (0x00002b643924d000) libc.so.6 => /lib64/libc.so.6 (0x00002b64394e4000) /lib64/ld-linux-x86-64.so.2 (0x0000003b2ba00000)
The sysadmins have provided a gcc 4.4.0 compiler that I access using symlinks on my $PATH: -bash-3.2$ which gcc g++ gfortran ~/local/bin/gcc ~/local/bin/g++ ~/local/bin/gfortran -bash-3.2$ ls -l ~/local/bin lrwxrwxrwx 1 rowen astro 14 Oct 28 2010 g++ -> /usr/bin/g++44 lrwxrwxrwx 1 rowen astro 14 Oct 28 2010 gcc -> /usr/bin/gcc44 lrwxrwxrwx 1 rowen astro 19 Dec 5 16:40 gfortran -> /usr/bin/gfortran44 -bash-3.2$ gfortran --version GNU Fortran (GCC) 4.4.0 20090514 (Red Hat 4.4.0-6) Copyright (C) 2009 Free Software Foundation, Inc.
For this log I used a home-bulit python 2.6.5 that is widely used. However, I've tried it with other builds of python that are on our system, as well, with no better success (including a Python 2.7.2). -bash-3.2$ which python /astro/apps/pkg/python64/bin/python -bash-3.2$ python Python 2.6.5 (r265:79063, Aug 4 2010, 11:27:53) [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
numpy seems to see gfortran when it builds:
-bash-3.2$ python setup.py build --fcompiler=gnu95
Running from numpy source directory.non-existing path in 'numpy/distutils': 'site.cfg' F2PY Version 2 blas_opt_info: blas_mkl_info: ... NOT AVAILABLE
atlas_blas_threads_info: ... NOT AVAILABLE
atlas_blas_info: ... NOT AVAILABLE
blas_info: ... FOUND: libraries = ['blas'] library_dirs = ['/usr/lib64'] language = f77
FOUND: libraries = ['blas'] library_dirs = ['/usr/lib64'] define_macros = [('NO_ATLAS_INFO', 1)] language = f77
lapack_opt_info: lapack_mkl_info: mkl_info: ... NOT AVAILABLE
NOT AVAILABLE
atlas_threads_info: ... NOT AVAILABLE
atlas_info: ... NOT AVAILABLE
/astro/users/rowen/build/numpy-1.6.1/numpy/distutils/system_info.py:1330: UserWarning: Atlas (http://math-atlas.sourceforge.net/) libraries not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [atlas]) or by setting the ATLAS environment variable. warnings.warn(AtlasNotFoundError.__doc__) lapack_info: libraries lapack not found in /astro/apps/lsst_w12_sl5/Linux64/external/python/2.7.2+2/lib ... FOUND: libraries = ['lapack'] library_dirs = ['/usr/lib64'] language = f77
FOUND: libraries = ['lapack', 'blas'] library_dirs = ['/usr/lib64'] define_macros = [('NO_ATLAS_INFO', 1)] language = f77
running build running config_cc unifing config_cc, config, build_clib, build_ext, build commands --compiler options running config_fc unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options running build_src build_src building py_modules sources creating build creating build/src.linux-x86_64-2.7 creating build/src.linux-x86_64-2.7/numpy creating build/src.linux-x86_64-2.7/numpy/distutils building library "npymath" sources customize Gnu95FCompiler Found executable /astro/users/rowen/local/bin/gfortran
# I install it in an out-of-the-way location just so I can test it -bash-3.2$ python setup.py install --home=~/local ... -bash-3.2$ cd -bash-3.2$ python
import numpy numpy.__path__ ['/astro/users/rowen/local/lib/python/numpy'] numpy.test() Running unit tests for numpy NumPy version 1.6.1 NumPy is installed in /astro/users/rowen/local/lib/python/numpy Python version 2.6.5 (r265:79063, Aug 4 2010, 11:27:53) [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] nose version 0.11.4 .... ====================================================================== FAIL: test_lapack (test_build.TestF77Mismatch)
Traceback (most recent call last): File "/astro/users/rowen/local/lib/python/numpy/testing/decorators.py", line 146, in skipper_func return f(*args, **kwargs) File "/astro/users/rowen/local/lib/python/numpy/linalg/tests/test_build.py", line 50, in test_lapack information.""") AssertionError: Both g77 and gfortran runtimes linked in lapack_lite ! This is likely to cause random crashes and wrong results. See numpy INSTALL.txt for more information.
---------------------------------------------------------------------- Ran 3533 tests in 13.400s
Any suggestions on how to fix this?
I assume you have g77 installed and on your PATH. If so, try moving it off your path. Ralf
In article <CABL7CQjeZMtsWcUPj0Kgfjz4XC4aRrwn24Bi3svzjwcc2t9ZWA@mail.gmail.com>, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Fri, Dec 9, 2011 at 8:02 PM, Russell E. Owen <rowen@uw.edu> wrote:
I'm trying to build numpy 1.6.1 on Scientific Linux 5 but the unit tests claim the wrong version of fortran was used. I thought I knew how to avoid that, but it's not working.
...(elided text that suggests numpy is building using g77 even though I asked for gfortran)...
Any suggestions on how to fix this?
I assume you have g77 installed and on your PATH. If so, try moving it off your path.
Yes. I would have tried that if I had known how to do it (though I'm puzzled why it would be wanted since I told the installer to use gfortran). The problem is that g77 is in /usr/bin/ and I don't have root privs on this system. -- Russell
2011/12/12 Russell E. Owen <rowen@uw.edu>
In article <CABL7CQjeZMtsWcUPj0Kgfjz4XC4aRrwn24Bi3svzjwcc2t9ZWA@mail.gmail.com>, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Fri, Dec 9, 2011 at 8:02 PM, Russell E. Owen <rowen@uw.edu> wrote:
I'm trying to build numpy 1.6.1 on Scientific Linux 5 but the unit tests claim the wrong version of fortran was used. I thought I knew how to avoid that, but it's not working.
...(elided text that suggests numpy is building using g77 even though I asked for gfortran)...
Any suggestions on how to fix this?
I assume you have g77 installed and on your PATH. If so, try moving it off your path.
Yes. I would have tried that if I had known how to do it (though I'm puzzled why it would be wanted since I told the installer to use gfortran).
The problem is that g77 is in /usr/bin/ and I don't have root privs on this system.
-- Russell
You could create a link g77 -> gfortran and make sure this link comes first in your PATH. (That's assuming command lines for g77 and gfortran are compatible -- I don't know if that's the case). -=- Olivier
In article <CAFXk4brJwX_WhSh7v_b62Ug+3Q2CTqvEwgcTf-P-ATFE4hqVTQ@mail.gmail.com>, Olivier Delalleau <shish@keba.be> wrote:
2011/12/12 Russell E. Owen <rowen@uw.edu>
In article <CABL7CQjeZMtsWcUPj0Kgfjz4XC4aRrwn24Bi3svzjwcc2t9ZWA@mail.gmail.com>, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Fri, Dec 9, 2011 at 8:02 PM, Russell E. Owen <rowen@uw.edu> wrote:
I'm trying to build numpy 1.6.1 on Scientific Linux 5 but the unit tests claim the wrong version of fortran was used. I thought I knew how to avoid that, but it's not working.
...(elided text that suggests numpy is building using g77 even though I asked for gfortran)...
Any suggestions on how to fix this?
I assume you have g77 installed and on your PATH. If so, try moving it off your path.
Yes. I would have tried that if I had known how to do it (though I'm puzzled why it would be wanted since I told the installer to use gfortran).
The problem is that g77 is in /usr/bin/ and I don't have root privs on this system.
-- Russell
You could create a link g77 -> gfortran and make sure this link comes first in your PATH. (That's assuming command lines for g77 and gfortran are compatible -- I don't know if that's the case).
Interesting idea. I gave it a try (see P.S.), but it didn't help. I get the same error in the unit test. -- Russell P.S. -bash-3.2$ which g77 ~/local/bin/g77 -bash-3.2$ ls -l ~/local/bin/g77 lrwxrwxrwx 1 rowen astro 19 Dec 20 10:59 /astro/users/rowen/local/bin/g77 -> /usr/bin/gfortran44 -bash-3.2$ g77 --version GNU Fortran (GCC) 4.4.0 20090514 (Red Hat 4.4.0-6) Copyright (C) 2009 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING
In article <rowen-74BAFA.11292712122011@news.gmane.org>, "Russell E. Owen" <rowen@uw.edu> wrote:
In article <CABL7CQjeZMtsWcUPj0Kgfjz4XC4aRrwn24Bi3svzjwcc2t9ZWA@mail.gmail.com>, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Fri, Dec 9, 2011 at 8:02 PM, Russell E. Owen <rowen@uw.edu> wrote:
I'm trying to build numpy 1.6.1 on Scientific Linux 5 but the unit tests claim the wrong version of fortran was used. I thought I knew how to avoid that, but it's not working.
...(elided text that suggests numpy is building using g77 even though I asked for gfortran)...
Any suggestions on how to fix this?
I assume you have g77 installed and on your PATH. If so, try moving it off your path.
Yes. I would have tried that if I had known how to do it (though I'm puzzled why it would be wanted since I told the installer to use gfortran).
The problem is that g77 is in /usr/bin/ and I don't have root privs on this system.
I'm starting to suspect this is a bug in the unit test, not the building of numpy. The unit test complains: Traceback (most recent call last): File "/astro/users/rowen/local/lib/python/numpy/testing/decorators.py", line 146, in skipper_func return f(*args, **kwargs) File "/astro/users/rowen/local/lib/python/numpy/linalg/tests/test_build.py", line 50, in test_lapack information.""") AssertionError: Both g77 and gfortran runtimes linked in lapack_lite ! This is likely to but when I run ldd on numpy/linalg/lapack_lite.so I get: -bash-3.2$ ldd /astro/users/rowen/local/lib/python/numpy/linalg/lapack_lite.so linux-vdso.so.1 => (0x00007fff0cff0000) liblapack.so.3 => /usr/lib64/liblapack.so.3 (0x00002acadd738000) libblas.so.3 => /usr/lib64/libblas.so.3 (0x00002acadde42000) libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00002acade096000) libm.so.6 => /lib64/libm.so.6 (0x00002acade380000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002acade604000) libc.so.6 => /lib64/libc.so.6 (0x00002acade812000) libgfortran.so.1 => /usr/lib64/libgfortran.so.1 (0x00002acadeb6a000) /lib64/ld-linux-x86-64.so.2 (0x0000003b2ba00000) The build instructions say (sic): 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 a dependency, gfortran has been used. If both are dependencies, this means both have been used, which is almost always a very bad idea. I don't see any sign of libg2c.so. Is there some other evidence that numpy/linalg/lapack_lite.so is build against both g77 and gfortran, or is the unit test result wrong or...? -- Russell
On Tue, Dec 20, 2011 at 10:52 PM, Russell E. Owen <rowen@uw.edu> wrote:
In article <rowen-74BAFA.11292712122011@news.gmane.org>, "Russell E. Owen" <rowen@uw.edu> wrote:
In article <CABL7CQjeZMtsWcUPj0Kgfjz4XC4aRrwn24Bi3svzjwcc2t9ZWA@mail.gmail.com>, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Fri, Dec 9, 2011 at 8:02 PM, Russell E. Owen <rowen@uw.edu> wrote:
I'm trying to build numpy 1.6.1 on Scientific Linux 5 but the unit tests claim the wrong version of fortran was used. I thought I knew how to avoid that, but it's not working.
...(elided text that suggests numpy is building using g77 even though I asked for gfortran)...
Any suggestions on how to fix this?
I assume you have g77 installed and on your PATH. If so, try moving it off your path.
Yes. I would have tried that if I had known how to do it (though I'm puzzled why it would be wanted since I told the installer to use gfortran).
The problem is that g77 is in /usr/bin/ and I don't have root privs on this system.
The explanation of why g77 is still picked up, and a possible solution: http://thread.gmane.org/gmane.comp.python.numeric.general/13820/focus=13826
Ralf
I'm starting to suspect this is a bug in the unit test, not the building of numpy. The unit test complains: Traceback (most recent call last): File "/astro/users/rowen/local/lib/python/numpy/testing/decorators.py", line 146, in skipper_func return f(*args, **kwargs) File "/astro/users/rowen/local/lib/python/numpy/linalg/tests/test_build.py", line 50, in test_lapack information.""") AssertionError: Both g77 and gfortran runtimes linked in lapack_lite ! This is likely to
but when I run ldd on numpy/linalg/lapack_lite.so I get: -bash-3.2$ ldd /astro/users/rowen/local/lib/python/numpy/linalg/lapack_lite.so linux-vdso.so.1 => (0x00007fff0cff0000) liblapack.so.3 => /usr/lib64/liblapack.so.3 (0x00002acadd738000) libblas.so.3 => /usr/lib64/libblas.so.3 (0x00002acadde42000) libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00002acade096000) libm.so.6 => /lib64/libm.so.6 (0x00002acade380000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002acade604000) libc.so.6 => /lib64/libc.so.6 (0x00002acade812000) libgfortran.so.1 => /usr/lib64/libgfortran.so.1 (0x00002acadeb6a000) /lib64/ld-linux-x86-64.so.2 (0x0000003b2ba00000)
The build instructions say (sic): 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 a dependency, gfortran has been used. If both are dependencies, this means both have been used, which is almost always a very bad idea.
I don't see any sign of libg2c.so.
Is there some other evidence that numpy/linalg/lapack_lite.so is build against both g77 and gfortran, or is the unit test result wrong or...?
In article <CABL7CQi_jQZgHa5rL8aSsb_PEmAPTNXyUyQutgQtz=_Ljux9hA@mail.gmail.com>, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Tue, Dec 20, 2011 at 10:52 PM, Russell E. Owen <rowen@uw.edu> wrote:
In article <rowen-74BAFA.11292712122011@news.gmane.org>, "Russell E. Owen" <rowen@uw.edu> wrote:
In article <CABL7CQjeZMtsWcUPj0Kgfjz4XC4aRrwn24Bi3svzjwcc2t9ZWA@mail.gmail.com>, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Fri, Dec 9, 2011 at 8:02 PM, Russell E. Owen <rowen@uw.edu> wrote:
I'm trying to build numpy 1.6.1 on Scientific Linux 5 but the unit tests claim the wrong version of fortran was used. I thought I knew how to avoid that, but it's not working.
...(elided text that suggests numpy is building using g77 even though I asked for gfortran)...
Any suggestions on how to fix this?
I assume you have g77 installed and on your PATH. If so, try moving it off your path.
Yes. I would have tried that if I had known how to do it (though I'm puzzled why it would be wanted since I told the installer to use gfortran).
The problem is that g77 is in /usr/bin/ and I don't have root privs on this system.
The explanation of why g77 is still picked up, and a possible solution: http://thread.gmane.org/gmane.comp.python.numeric.general/13820/focus=13826
Thank you. I assume you are referring to this answer:
You mean g77? Anyways, I think I know why you are having problems. Passing --fcompiler to the config command only affects the Fortran compiler that is used during configuration phase (where we compile small C programs to determine what your platform supports, like isnan() and the like). It does not propagate to the > rest of the build_ext phase where you want it. Use config_fc to set up your Fortran compiler for all of the phases:
$ python setup.py config_fc --fcompiler=gnu95 build
Fascinating. However, there are two things I don't understand: 1) Is my build actually broken? The ldd output for lapack_lite has no sign of libg2c.so (see quote from build instructions below). If it's just a false report from the unit then I don't need to rebuild (and there are a lot of packages built against it -- a rebuild will take much of a day). 2) This advice seems to contradict the build documentation (see below). Does this indicate a bug in the docs? In setup.py? Some other issue? I don't remember ever having this problem building numpy before. Quote from the build docs: <http://docs.scipy.org/doc/numpy/user/install.html> Choosing the fortran compiler To build with g77: python setup.py build --fcompiler=gnu To build with gfortran: python setup.py build --fcompiler=gnu95 For more information see: python setup.py build --help-fcompiler 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 a dependency, gfortran has been used. If both are dependencies, this means both have been used, which is almost always a very bad idea. ----- ldd on my numpy/linalg/lapack_lite.so (I don't see libg2c.so): -bash-3.2$ ldd /astro/users/rowen/local/lib/python/numpy/linalg/lapack_lite.so linux-vdso.so.1 => (0x00007fff0cff0000) liblapack.so.3 => /usr/lib64/liblapack.so.3 (0x00002acadd738000) libblas.so.3 => /usr/lib64/libblas.so.3 (0x00002acadde42000) libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00002acade096000) libm.so.6 => /lib64/libm.so.6 (0x00002acade380000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002acade604000) libc.so.6 => /lib64/libc.so.6 (0x00002acade812000) libgfortran.so.1 => /usr/lib64/libgfortran.so.1 (0x00002acadeb6a000) /lib64/ld-linux-x86-64.so.2 (0x0000003b2ba00000)
In article <CABL7CQi_jQZgHa5rL8aSsb_PEmAPTNXyUyQutgQtz=_Ljux9hA@mail.gmail.com>, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Tue, Dec 20, 2011 at 10:52 PM, Russell E. Owen <rowen@uw.edu> wrote:
In article <rowen-74BAFA.11292712122011@news.gmane.org>, "Russell E. Owen" <rowen@uw.edu> wrote:
In article <CABL7CQjeZMtsWcUPj0Kgfjz4XC4aRrwn24Bi3svzjwcc2t9ZWA@mail.gmail.com>, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Fri, Dec 9, 2011 at 8:02 PM, Russell E. Owen <rowen@uw.edu> wrote:
I'm trying to build numpy 1.6.1 on Scientific Linux 5 but the unit tests claim the wrong version of fortran was used. I thought I knew how to avoid that, but it's not working.
...(elided text that suggests numpy is building using g77 even though I asked for gfortran)...
Any suggestions on how to fix this?
I assume you have g77 installed and on your PATH. If so, try moving it off your path.
Yes. I would have tried that if I had known how to do it (though I'm puzzled why it would be wanted since I told the installer to use gfortran).
The problem is that g77 is in /usr/bin/ and I don't have root privs on this system.
The explanation of why g77 is still picked up, and a possible solution: http://thread.gmane.org/gmane.comp.python.numeric.general/13820/focus=13826
OK. I tried this: - clear out old numpy from ~/local - unpack fresh numpy 1.6.1 in a build directory and cd into it $ python setup.py config_fc --fcompiler=gnu95 build $ python setup.py install --home=~/local $ cd $ python $ import numpy $ numpy.__file__ # to make sure it picked up the newly build version $ numpy.test() Again the unit test fails with: FAIL: test_lapack (test_build.TestF77Mismatch) ---------------------------------------------------------------------- Traceback (most recent call last): File "/astro/users/rowen/local/lib/python/numpy/testing/decorators.py", line 146, in skipper_func return f(*args, **kwargs) File "/astro/users/rowen/local/lib/python/numpy/linalg/tests/test_build.py", line 50, in test_lapack information.""") AssertionError: Both g77 and gfortran runtimes linked in lapack_lite ! This is likely to cause random crashes and wrong results. See numpy INSTALL.txt for more information. -- Russell P.S. I'm using nose 0.11.4 because the current version requires distrib. Surely that won't affect this?
In article <CABL7CQi_jQZgHa5rL8aSsb_PEmAPTNXyUyQutgQtz=_Ljux9hA@mail.gmail.com>, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Tue, Dec 20, 2011 at 10:52 PM, Russell E. Owen <rowen@uw.edu> wrote:
In article <rowen-74BAFA.11292712122011@news.gmane.org>, "Russell E. Owen" <rowen@uw.edu> wrote:
In article <CABL7CQjeZMtsWcUPj0Kgfjz4XC4aRrwn24Bi3svzjwcc2t9ZWA@mail.gmail.com , Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Fri, Dec 9, 2011 at 8:02 PM, Russell E. Owen <rowen@uw.edu> wrote:
I'm trying to build numpy 1.6.1 on Scientific Linux 5 but the unit tests claim the wrong version of fortran was used. I thought I knew how to avoid that, but it's not working.
...(elided text that suggests numpy is building using g77 even though I asked for gfortran)...
Any suggestions on how to fix this?
I assume you have g77 installed and on your PATH. If so, try moving it off your path.
Yes. I would have tried that if I had known how to do it (though I'm puzzled why it would be wanted since I told the installer to use gfortran).
The problem is that g77 is in /usr/bin/ and I don't have root privs on this system.
The explanation of why g77 is still picked up, and a possible solution:
http://thread.gmane.org/gmane.comp.python.numeric.general/13820/focus=13826
OK. I tried this: - clear out old numpy from ~/local - unpack fresh numpy 1.6.1 in a build directory and cd into it $ python setup.py config_fc --fcompiler=gnu95 build $ python setup.py install --home=~/local $ cd $ python $ import numpy $ numpy.__file__ # to make sure it picked up the newly build version $ numpy.test()
Again the unit test fails with: FAIL: test_lapack (test_build.TestF77Mismatch) ---------------------------------------------------------------------- Traceback (most recent call last): File "/astro/users/rowen/local/lib/python/numpy/testing/decorators.py", line 146, in skipper_func return f(*args, **kwargs) File "/astro/users/rowen/local/lib/python/numpy/linalg/tests/test_build.py", line 50, in test_lapack information.""") AssertionError: Both g77 and gfortran runtimes linked in lapack_lite ! This is likely to cause random crashes and wrong results. See numpy INSTALL.txt for more information.
Looks like the test is incorrect. For some reason you have both
On Wed, Dec 21, 2011 at 10:05 PM, Russell E. Owen <rowen@uw.edu> wrote: libgfortran.so.3 and libgfortran.so.1 on separate lines of your ldd output. This causes FindDependenciesLdd to return a list of length 2, which is interpreted as having found both g77 and gfortran. So no problem I think, although I don't understand why two different gfortran binaries are picked up. Ralf
participants (3)
-
Olivier Delalleau -
Ralf Gommers -
Russell E. Owen