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