Does anyone use SAGE_ATLAS_LIB ?
Dr. David Kirkby
Solaris. When I tested it on Solaris it worked of course.
kirkby@sage:~/sage-4.5.alpha4$ export SAGE_ATLAS_LIB=/tmp
kirkby@sage:~/sage-4.5.alpha4$ export SAGE_ATLAS_LIB=/home/kirkby/sage-4.4.3/local
kirkby@sage:~/sage-4.5.alpha4$ ls /home/kirkby/sage-4.4.3/local/lib/libla*
/home/kirkby/sage-4.4.3/local/lib/liblapack.a
When I tested on Linux, the code did not work. I tried an old version on
sage.math, that did not work either. Each time, I get the message that one of
the libraries is missing: - see below.
Unable to find one of liblapack.so, libcblas.so, libatlas.so, or libf77blas.so
in supplied directory.
Set SAGE_ATLAS_LIB to the lib directory of
liblapack.so,libcblas.so,libatlas.so,libf77blas.so,
to use existing atlas libraries, or unset SAGE_ATLAS_LIB to build one from source.
When I looked at the code, there's a test for liblapack.so. That library is
never made on Solaris, but it does not appear it's made on Linux either. Not one
single build I have on sage.math has liblapack.so
kirkby@sage:~$ find . -name liblapack.so
kirkby@sage:~$ find . -name liblapack.a
./sage-4.5.alpha4/local/lib/liblapack.a
./sage-4.5/local/lib/liblapack.a
./sage-4.4.3/local/lib/liblapack.a
./sage-4.4.3/dist/sage-4.4.3-sage.math-x86_64-Linux/local/lib/liblapack.a
./sage-4.4.3/dist/tmp/sage-4.4.3-sage.math-x86_64-Linux/local/lib/liblapack.a
./atlas-build/lib/liblapack.a
./sage-4.4.2/local/lib/liblapack.a
Since the script system_atlas.py tests for liblapack.so, and will generate an
error message if it does not exists, I can't possibly see how SAGE_ATLAS_LIB
ever works for anyone on Linux.
If you look at the code, do not look at sage-4.5.3 or later, as there were some
Solaris-specific changes made there on #9356. I suspect this has been broken for
some time.
Am I missing something?
Dave
Dr. David Kirkby
Solaris. When I tested it on Solaris it worked of course.
When I tested on Linux, the code did not work. I tried an old version on
sage.math, that did not work either. Each time, I get the message that one of
the libraries is missing: - see below.
Unable to find one of liblapack.so, libcblas.so, libatlas.so, or libf77blas.so
in supplied directory.
Set SAGE_ATLAS_LIB to the lib directory of
liblapack.so,libcblas.so,libatlas.so,libf77blas.so,
to use existing atlas libraries, or unset SAGE_ATLAS_LIB to build one from source.
When I looked at the file system_atlas.py, there's a test for liblapack.so. That
library is never made on Solaris, but it does not appear it's made on Linux
either. Not one single build I have on sage.math has liblapack.so
kirkby@sage:~$ find . -name liblapack.so
kirkby@sage:~$ find . -name liblapack.a
./sage-4.5.alpha4/local/lib/liblapack.a
./sage-4.5/local/lib/liblapack.a
./sage-4.4.3/local/lib/liblapack.a
./sage-4.4.3/dist/sage-4.4.3-sage.math-x86_64-Linux/local/lib/liblapack.a
./sage-4.4.3/dist/tmp/sage-4.4.3-sage.math-x86_64-Linux/local/lib/liblapack.a
./atlas-build/lib/liblapack.a
./sage-4.4.2/local/lib/liblapack.a
So looking at the libraries I have, and how system_atlas.py is written, I can't
see how SAGE_ATLAS_LIB how SAGE_ATLAS_LIB works for anyone.
François Bissey
> ./sage-4.4.2/local/lib/liblapack.a
>
>
> Since the script system_atlas.py tests for liblapack.so, and will generate
> an error message if it does not exists, I can't possibly see how
> SAGE_ATLAS_LIB ever works for anyone on Linux.
>
> If you look at the code, do not look at sage-4.5.3 or later, as there were
> some Solaris-specific changes made there on #9356. I suspect this has been
> broken for some time.
>
> Am I missing something?
>
If you use SAGE_ATLAS_LIB you use a set of libraries installed outside of
sage. Either you built it yourself or it is provided by your system.
Gentoo install liblapack.so - so it should work for me. I don't know about
other distros.
On the other hand there is a real problem, I think, in the way libcblas.so and
liblapack.so are generated in sage as their production often fails.
Francois
Dr. David Kirkby
>> I've made a couple of changes to the ATLAS package so SAGE_ATLAS_LIB works
>> on Solaris. When I tested it on Solaris it worked of course.
<snip>
Francois,
if I build Sage 4.4.1 in one directory from scratch, then I try to build a later
version (sage 4.5.0) in another directory, is setting SAGE_ATLAS_LIB to the
directory where the previous version was built in Sage not acceptable?
That can be made to work on Solaris, by
* Not building liblapack.so - it often screws things up.
* Checking for liblapack.a rather than liblapack.so
* Creating a symbolic link from the previously built liblapack.a to
$SAGE_LOCAL/lib.
> On the other hand there is a real problem, I think, in the way libcblas.so and
> liblapack.so are generated in sage as their production often fails.
OK, that explains it. The reason the SAGE_ATLAS_LIB is not working on Linux is
that liblapack.so is failing to build. When that happens, it means one can't use
a previous build of ATLAS, since liblapack.so would have failed to build.
Since laplapack.a is always built, does it seem sensible to change the test from
using liblapack.so to using liblapack.so? That way it should work on all systems?
That actually makes the code a lot cleaner, as it removes the need to have
Solaris-specific tests everywhere.
It seems to me that
* liblapack.so often fails to build on Linux
* Will screw things up if one does build it on Solaris.
Therefor the solution seems simple - use the static library instead.
> Francois
>
Dave
Dr. David Kirkby
> On the other hand there is a real problem, I think, in the way libcblas.so and
> liblapack.so are generated in sage as their production often fails.
>
> Francois
>
Are you sure it is libcblas.so that's presenting problems and not libf77blas.so?
As far as I can tell:
* On both Solaris and Linux, liblapack.so are *not* generated properly.
* On Linux, libf77blas.so is *not* generated properly. (That's ok on Solaris)
This makes me question whether we should be generating the shared libraries at
all. If that rather inappropriately named script 'make_correct_shared.sh' does
not work, why the hell should we be using it?
Dave
Willem Jan Palenstijn
> On 09/ 6/10 01:46 PM, Fran?ois Bissey wrote:
>> On the other hand there is a real problem, I think, in the way libcblas.so
>> and liblapack.so are generated in sage as their production often fails.
>
> libf77blas.so?
>
> As far as I can tell:
>
> * On both Solaris and Linux, liblapack.so are *not* generated properly.
> * On Linux, libf77blas.so is *not* generated properly. (That's ok on Solaris)
>
> This makes me question whether we should be generating the shared
> libraries at all. If that rather inappropriately named script
> 'make_correct_shared.sh' does not work, why the hell should we be using
> it?
I haven't followed the rest of the thread very closely, but doesn't #9600
address the issue with make_correct_shared.sh?
-Willem Jan
Dr. David Kirkby
Clearly Wolfram Research see no need to generate the shared libraries. It makes
me wonder if we really need them at all.
drkirkby@hawk:/usr/local/Wolfram$ find . -name 'liblapack.*'
./Mathematica/7.0.1/SystemFiles/Libraries/Solaris-x86-64/liblapack.a
drkirkby@hawk:/usr/local/Wolfram$ find . -name 'libatlas.*'
./Mathematica/7.0.1/SystemFiles/Libraries/Solaris-x86-64/libatlas.a
drkirkby@hawk:/usr/local/Wolfram$ find . -name 'libcblas.*'
./Mathematica/7.0.1/SystemFiles/Libraries/Solaris-x86-64/libcblas.a
drkirkby@hawk:/usr/local/Wolfram$ find . -name 'libf77blas.*'
./Mathematica/7.0.1/SystemFiles/Libraries/Solaris-x86-64/libf77blas.a
Whilst I can't speak for libatlas.so or libcblas.so, it appears Sage works fine
without liblapack.so & libf77blas.so on Linux, and at least without liblapack.so
on Solaris.
*Perhaps* generating the shared libraries libatlas.so or libcblas.so is
worthwhile, but the other two are problematic on Linux and one is problematic on
Solaris.
On OS X, Sage only tries to generate two shared libraries - libatlas.dylib and
libcblas.dylib. No attempt is even made to generate the other two - which
happens to be the two generating problems on Linux.
Dave
Dr. David Kirkby
No firm conclusions seem to be reached on that ticket, but the implied
assumption seems to be that we need to make the shared libraries. Everything on
that ticket is about building them - what options work, what don't, etc.
But the more important question is whether we need them at all. I think there's
evidence we don't need them at all, and so building them is a waste of
time/effort etc.
Let's look at the evidence
* Wolfram Research do not ship any of them shared with Mathematica - they are
all static. But Wolfram Research ship mainly shared libraries - only a small
number they included are static.
* Only two are *attempted* to be be built shared on OX X (libatlas & libcblas)
* The two we build on OS X are the only two which reliably build on Linux.
* liblapack.so, whilst it can be built on Solaris, it does not actually work,
so it's not built at all on Solaris.
I postulate that just including the static libararies, or possibly the static
plus shared versions of libatlas & libcblas, is all we need to do.
Does that make any sense?
I don't know about FreeBSD, but the OS X/Linux/Solaris situation seems pretty
clear to me.
Dave
François Bissey
shared libraries, nice to have but not strictly necessary.
I am backing you up on that one until it is properly fixed.
I will look at that ticket but I think sage's BLAS/LAPACK
subsytstem needs a big revamp if we are going to use
shared libraries by default.
Note that until recently ATLAS was tricky to build with shared
libraries - and certainly not the way it is currently done in sage.
We had a big libtool patch in Gentoo to deal with this. I think
most of the patch has been accepted in 3.9.24 so it may be
easier to build proper shared objects with 3.9.24+.
Building a shared liblapack.so from there is still tricky though.
Francois
Dr. David Kirkby
> Hi Dave,
>
> shared libraries, nice to have but not strictly necessary.
> I am backing you up on that one until it is properly fixed.
> I will look at that ticket but I think sage's BLAS/LAPACK
> subsytstem needs a big revamp if we are going to use
> shared libraries by default.
Yes.
> Note that until recently ATLAS was tricky to build with shared
> libraries - and certainly not the way it is currently done in sage.
> We had a big libtool patch in Gentoo to deal with this. I think
> most of the patch has been accepted in 3.9.24 so it may be
> easier to build proper shared objects with 3.9.24+.
> Building a shared liblapack.so from there is still tricky though.
>
> Francois
I think given this, we should only checked for static libraries in the file
system_atlas.p, which is used when SAGE_ATLAS_LIB is set. Otherwise
SAGE_ATLAS_LIB fails to work if one of the shared libraries is missing. It's
pointless testing for libraries that are unreliably built, when there are
perfectly built versions.
I'm just going to build and doctest Sage on Linux and Solaris with the changes I
made. If they work, I'll post a revised .spkg which does not check for the
shared libraries.
I don't intend messing around just now with what gets built and what does not,
as that may be addressed if we update ATLAS. But currently the failure of these
libraries to build is meaning SAGE_ATLAS_LIB can't be used. That's a real pain
on t2.math, as ATLAS takes 7 hours to build.
Dave