<br><br><div class="gmail_quote">On Tue, Dec 20, 2011 at 10:52 PM, Russell E. Owen <span dir="ltr"><<a href="mailto:rowen@uw.edu">rowen@uw.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In article <<a href="mailto:rowen-74BAFA.11292712122011@news.gmane.org">rowen-74BAFA.11292712122011@news.gmane.org</a>>,<br>
<div class="im"> "Russell E. Owen" <<a href="mailto:rowen@uw.edu">rowen@uw.edu</a>> wrote:<br>
<br>
> In article<br>
> <<a href="mailto:CABL7CQjeZMtsWcUPj0Kgfjz4XC4aRrwn24Bi3svzjwcc2t9ZWA@mail.gmail.com">CABL7CQjeZMtsWcUPj0Kgfjz4XC4aRrwn24Bi3svzjwcc2t9ZWA@mail.gmail.com</a>>,<br>
>  Ralf Gommers <<a href="mailto:ralf.gommers@googlemail.com">ralf.gommers@googlemail.com</a>> wrote:<br>
><br>
> > On Fri, Dec 9, 2011 at 8:02 PM, Russell E. Owen <<a href="mailto:rowen@uw.edu">rowen@uw.edu</a>> wrote:<br>
> ><br>
> > > I'm trying to build numpy 1.6.1 on Scientific Linux 5 but the unit tests<br>
> > > claim the wrong version of fortran was used. I thought I knew how to<br>
> > > avoid that, but it's not working.<br>
> > ><br>
> > >...(elided text that suggests numpy is building using g77 even though I<br>
> > >asked for gfortran)...<br>
> > ><br>
> > > Any suggestions on how to fix this?<br>
> > ><br>
> ><br>
> > I assume you have g77 installed and on your PATH. If so, try moving it off<br>
> > your path.<br>
><br>
> Yes. I would have tried that if I had known how to do it (though I'm<br>
> puzzled why it would be wanted since I told the installer to use<br>
> gfortran).<br>
><br>
> The problem is that g77 is in /usr/bin/ and I don't have root privs on<br>
> this system.<br>
<br></div></blockquote><div>The explanation of why g77 is still picked up, and a possible solution: <a href="http://thread.gmane.org/gmane.comp.python.numeric.general/13820/focus=13826">http://thread.gmane.org/gmane.comp.python.numeric.general/13820/focus=13826</a><br>
<br>Ralf<br><br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
</div>I'm starting to suspect this is a bug in the unit test, not the building<br>
of numpy. The unit test complains:<br>
Traceback (most recent call last):<br>
  File<br>
"/astro/users/rowen/local/lib/python/numpy/testing/decorators.py", line<br>
146, in skipper_func<br>
    return f(*args, **kwargs)<br>
  File<br>
"/astro/users/rowen/local/lib/python/numpy/linalg/tests/test_build.py",<br>
line 50, in test_lapack<br>
    information.""")<br>
AssertionError: Both g77 and gfortran runtimes linked in lapack_lite !<br>
This is likely to<br>
<br>
but when I run ldd on numpy/linalg/lapack_lite.so I get:<br>
-bash-3.2$ ldd<br>
/astro/users/rowen/local/lib/python/numpy/linalg/lapack_lite.so<br>
   linux-vdso.so.1 =>  (0x00007fff0cff0000)<br>
   liblapack.so.3 => /usr/lib64/liblapack.so.3 (0x00002acadd738000)<br>
   libblas.so.3 => /usr/lib64/libblas.so.3 (0x00002acadde42000)<br>
   libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00002acade096000)<br>
   libm.so.6 => /lib64/libm.so.6 (0x00002acade380000)<br>
   libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002acade604000)<br>
   libc.so.6 => /lib64/libc.so.6 (0x00002acade812000)<br>
   libgfortran.so.1 => /usr/lib64/libgfortran.so.1 (0x00002acadeb6a000)<br>
   /lib64/ld-linux-x86-64.so.2 (0x0000003b2ba00000)<br>
<br>
The build instructions say (sic):<br>
One relatively simple and reliable way to check for the compiler used to<br>
build a library is to use ldd on the library. If libg2c.so is a<br>
dependency, this means that g77 has been used. If libgfortran.so is a a<br>
dependency, gfortran has been used. If both are dependencies, this means<br>
both have been used, which is almost always a very bad idea.<br>
<br>
I don't see any sign of libg2c.so.<br>
<br>
Is there some other evidence that numpy/linalg/lapack_lite.so is build<br>
against both g77 and gfortran, or is the unit test result wrong or...?<br>
<span class="HOEnZb"></span><br></blockquote></div>