LAPACK from sage (i. e. usable in sage -sh) ?

[Emmanuel Charpentier]

Something just changed in the Sage build process : as of 7.4, LAPACK is no longer available to programs running in the Sage shell.

Case in point : I want to install JAGS (an MCMC sampler), which is needed by the rjags R package, of some use to Bayesian R users... This package compiled fine in the Sage shell up to Sage 7.4beta6. Now, the --configure step fails with :

checking for cheev_ in -llapack... no
checking for cheev_ in -llapack_rs6k... no
configure: error: "You need to install the LAPACK library"

Indeed :

charpent@asus16-ec:~$ find /usr/local/sage-7/ -iname "*lapack*so*"
/usr/local/sage-7/local/lib/R/modules/lapack.so
/usr/local/sage-7/local/lib/python2.7/site-packages/cvxopt/lapack.so
/usr/local/sage-7/local/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so
/usr/local/sage-7/local/lib/python2.7/site-packages/scipy/linalg/_flapack.so
/usr/local/sage-7/local/lib/python2.7/site-packages/scipy/linalg/cython_lapack.so
charpent@asus16-ec:~$ find /usr/local/sage-7/ -iname "*lapack*h*"
/usr/local/sage-7/local/lib/R/include/R_ext/Lapack.h
/usr/local/sage-7/local/include/lapacke_mangling.h
/usr/local/sage-7/local/include/linbox/algorithms/numeric-solver-lapack.h
/usr/local/sage-7/local/include/lapacke_config.h
/usr/local/sage-7/local/include/lapacke.h


Short of forcing the Sage build process to use the system's LAPACK (which can be done but, as far as I know, is not recommended), I don't see how to force the creation of this library and its header file.

Note that could be useful to reduce overhead : R (standard package) creates its own version (probably for lack of finding it at build time...) ; it also exists in the python package cvxopt.

1) What do you think ?

2) Should a ticket be filed ?

HTH,

--
Emmanuel Charpentier

[Francois Bissey]

This is because automatic blas/lapack detection is a hopeless task.
You should pass your lapack libraries to the configuration script.
If you can’t, hack it.
And now that we have switched to openblas, -lopenblas provides lapack.

François

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

[Emmanuel Charpentier]

Would it be sufficient to link libosympenblas.so to liblapack.so in $SAGE_ROOT/local/lib/ ?

Thanks for the hint !

--
Emmanuel Charpentier

[Francois Bissey]

libopenblas.so to liblapack.so? Yes it should and I think we even should do
it in spkg-install. Feel free to open a ticket.

François

[Emmanuel Charpentier]

I tried it, and it works for me (superficial test : jags compiles, the R packages using install, a,d an old R script runs).

This is now Trac#21736 . I won't do it immediately (my "woking Sage installation is somewhat patched, and going back to develop and forward to my branch costs about 30 minutes (compilation) + 70 minutes (ptestlong), so I need a new "pristine" tree...

Thanks for your help !

--
Emmanuel Charpentier

[Volker Braun]

We do have a pc file so IMHO the best way is to rely on the output of

$ pkg-config --cflags lapack

-I/mnt/disk/home/release/Sage/local/include

$ pkg-config --libs lapack

-L/mnt/disk/home/release/Sage/local/lib -lopenblas

[Francois Bissey]

I agree it would be best. Unfortunately it may not always be possible
to do that without heavy hacking.
Adding the liblapack link has trade-off, it would make some stuff work
out of the box but it could also hide problems on the long term.

Really upstream of any project using blas/lapack needs to have a way
to check a user provided configuration before trying a automated detection
routine. Looking at you numpy (does the reverse by default without hacking,
look at user provided configuration only when its auto detection has failed).

François

[Emmanuel Charpentier]

While it is the "right" solution, it seems a bit heavy handed to ask all authors of LAPACK-using programs susceptible to Sage's use to conform to the convention suggested by Volker. This might not even be possible, depending on system's infrastructure and source's configuration. And effectively forking all such LAPACK-using programs puts an heavy load on the users...

Meanwhile, this trivial patch needs review.

HTH,

--
Emmanuel Charpentier

[Francois Bissey]

Doesn’t have to use .pc - directly. But it has to be able to accept a user
configuration one way or another. Using .pc to provide said configuration
in a script is OK.
You might want to explore the way I did set up numpy in sage for example.

I looked at JAGS it takes --with-blas and —with-lapack options. You could
solve your problem by doing
—with-lapack=-lopenblas
or to keep with Volker spirit
—with-lapack=`pkg-cong —libs lapack`

Francois

[Emmanuel Charpentier]

Indeed... (I didn't saw the "--with-lapack" option. Time to change my spectacles?).

My patch has no use for this case. Can you think of other use cases ?

If not, this ticket should be resolved as "Invalid/won't fix"...

--
Emmanuel Charpentier

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscribe@googlegroups.com.

> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/3cPELP9DXKg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+unsubscribe@googlegroups.com.

[Francois Bissey]

Well, I have seen horrible stuff as package maintainer in a distro and
software installation specialist on a cluster. The cases where it would
be needed should be fixed upstream. However sometimes upstream is dead
or uncaring :(
In my opinion tentative of autodetection with an autotool script
or a cmake module is doomed (as in it can do a good job but if you are
in my job you will always make them run in a corner case they don’t).
It is far easier to provide a configuration option.

There are other tales to tell but they drift away from the initial
query.

François

> You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/3cPELP9DXKg/unsubscribe.

> To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.