SEGFAULT from importing _minpack.so (was Re: [SciPy-user] install

[eric]

> Tried to play with this stuff on Mandrake-8.1 and everything worked.
> Then, I discovered that Mandrake-8.2 g77 comes with two libraries:
> libg2c.a and libg2c-pic.a. Guess this might win a femtosecond
> or a nanobyte (my supposition is that there is a libg2c WITHOUT
> an a libg2c WITH position independent code -- but I should take
> a look in their gcc-2.96 RPM package to be sure -- and where do
> you report gcc-2.96 bugs?).
>
> So, I modified build_flib.py to replace the g77 library "g2c" by
> "g2c-pic" and now I can happily do "from scipy import *".

Hmmm.  Good detective work.  But... this is really goofy.  I can't imagine even
wanting to support detection of the g2c-pic library.  I curious as to why Travis
O's scipy builds fine without this library substitution.  His comment that he
had rebuilt python on his own might have an influence, but I don't think so --
especially since the RH compiled SciPy works fine on your machine.  Looking at
the gcc RPM sounds like a good plan.  I don't know where to report bugs though.

>
> But running "scipy.test()" dies with
>
> .zswap:n=3
> ....... ** On entry to DGESDD parameter number 12 had an illegal value
> [packer at venus packer]$
>
> This did not happen with the Red Hat compiled SciPy that I untarred
> (this SciPy is probably linked against a rather vanilla Atlas, isn't it?)

It is compiled on a Pentium III for Linux (P4 on windows), but both are set up
to build the generic version of ATLAS without SSE1 or SSE2 support.  So yes, it
is pretty vanilla.

>
> Anyhow, I plan to reinstall a gcc/g77-2.95.3 to rebuild the ATLAS
> libraries and to get rid of the libg2c-pic.a idiosyncrasy and will
> hopefully solve the DGESDD problem at the same time :-)

good plan.

>
> I will let you know. And Pearu, thanks a lot for your help and
> patience.
>
> Gerard.
> PS: how fundamental is Atlas to SciPy? Installing ATLAS is a big
> obstacle for most users. Could it be possible to make ATLAS optional?
> I have still a few old machines (150-300 MHz) and hate the prospect
> of installing Atlas on
> those.

I agree.  SciPy is starting to mature enough where non-geeks should be able to
install it.  ATLAS is definitely the biggest hurdle.  We could distribute the
SciPy tarballs with f2py rolled in so that Python and Numeric were the only
dependencies (and we *could* roll Numeric in to get rid of it as a dependency,
but it made some unhappy in the SciPy-0.1 release).  This assumes people have a
lapack and blas on their system (is this standard)?

There are several solutions to the ATLAS issue:

    1. Supply ATLAS binaries for the common platforms.
    2. Make the setup.py script work with the
       standard lapack and blas impelementation.

We are likely to supply some ATLAS binaries, but (1) is probably a bigger task
than I want to deal with.

As far as (2), there are currently two reasons we link to ALTAS.  The first is
speed.  The 2nd is that it has C versions of most of the interfaces which
theoretically should be faster because they don't require a memory transpose
before matrix operations.  There is probably some benefit to this on the faster
operations, but Pearu's test have shown that the commonly used matrix
factorizations (order N^3) overshadow the transpose time enough to make it
negligible.  It is probably a reasonable question whether the C interfaces are
really that important.  The speed issue really isn't that big of a deal.  People
who want speed can use ATLAS.  Others can link to the standard LAPACK and BLAS
libraries (which still take 10 or so minutes to build).

So the things that have to change for out-of-the-box building with non-ATLAS
libraries are

 (1) We would need to add a lapack_info to search for lapack and blas if
atlas_info failed to find the libraries.  This would be pretty much identical to
atlas_info, accept that it would only detect lapack and blas.

 (2) linalg_setup.py would have to check whether it was building with ATLAS or
with plain LAPACK.  If with the plain lapack, it would need to disable the build
of the clapack and cblas interfaces.

Pearu did a good job with linalg so that it actually detects whether the C
versions of the interfaces are present.  If they are, it uses them.  If not it
rolls to the fortran versions.  So, I don't think the switch would require any
changes to the actual SciPy code base (or minimal anyway).  It is only the build
process that needs changes.

On a side note, has anyone built against non ATLAS libraries?  Are there any
issues to watch out for?

eric




>
> ---------------------------------------------
> This message was sent using Endymion MailMan.
> http://www.endymion.com/products/mailman/
>
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>