[Numpy-discussion] trouble building numpy 1.6.1 on Scientific Linux 5

Ralf Gommers ralf.gommers at googlemail.com
Tue Dec 20 17:04:08 EST 2011


On Tue, Dec 20, 2011 at 10:52 PM, Russell E. Owen <rowen at uw.edu> wrote:

> In article <rowen-74BAFA.11292712122011 at news.gmane.org>,
>  "Russell E. Owen" <rowen at uw.edu> wrote:
>
> > In article
> > <CABL7CQjeZMtsWcUPj0Kgfjz4XC4aRrwn24Bi3svzjwcc2t9ZWA at mail.gmail.com>,
> >  Ralf Gommers <ralf.gommers at googlemail.com> wrote:
> >
> > > On Fri, Dec 9, 2011 at 8:02 PM, Russell E. Owen <rowen at 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...?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20111220/ccc3c19c/attachment.html>


More information about the NumPy-Discussion mailing list