#10508: Update ATLAS to stable version 3.10
-------------------------------------------------------+--------------------
Reporter: vbraun | Owner: tbd
Type: enhancement | Status:
needs_review
Priority: major | Milestone:
sage-5.4
Component: packages | Resolution:
Keywords: ATLAS | Work issues:
Report Upstream: Reported upstream. No feedback yet. | Reviewers:
Benjamin Jones, Karl-Dieter Crisman, Dmitrii Pasechnik, Georg Weber, François
Bissey, John Palmieri
Authors: Volker Braun | Merged in:
Dependencies: #13160 | Stopgaps:
-------------------------------------------------------+--------------------
Comment (by GeorgSWeber):
I ran also into the problem of comment 211, but I see that one is already
cared for.
The latest "pyx_preparse()" problem might not be entirely due to what is
done about "BLAS configuration/setup", and how it is done in
.../sage/misc/cython.py (see especially lines 64-67 in conjunction with
lines 78-79 and line 265 in that file), but certainly creates pretty
exactly the kind of problem observed in comment 216, and healed by the
symlink in comment 218. (It's quite a miracle to me, how that could have
ever worked before under OS X 10.4 PPC --- which I know it did!)
Which leaves us with either adjusting every occurence of BLAS
configuration/setup (sage/module_list.py lines 22-44, sage/misc/cython.py
lines as above, cvxopt and possibly yet another spkg or two, ...) for the
"OS X 10.4 PPC case" (we already *do* search for "/usr/lib/libclas.{so,
dylib}" in those places, and use that one if one can be found there, just
extend the search to
"/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib"
in case the former search failed), or else try the symlink approach. Or
some "hybrid" approach, symlinking only on OS X 10.4 PPC.
@Volker:
In comment 209 you wrote:
> I don't think we should be symlinking system libraries into local/lib if
we can avoid it.
So if you think that creating symlinks to "outside-of-sage" libraries in
$SAGE_ROOT/local/lib/ (and possibly to header files like "cblas.h" and
"clapack.h" in $SAGE_ROOT/local/include/, too) should be avoided, could
you please give some insights about the reasoning behind?
P.S.:
I can't find the following note about trying to actually *build and use*
ATLAS on OS X in the comments so far, so here it is: If we want to be able
to do so one day, at least the numpy build system needs to be patched
(somewhere in src/numpy/distutils/system_info.py, classes
"lapack_opt_info" and "blas_opt_info"), since there the usage of the
Accelerate framework on OS X is hardcoded --- which seems to be
problematic, if other parts of Sage do not use the same underlying LAPACK
and BLAS libraries. Essentially, one should be able to "just" re-use
patches from the respective Gentoo ebuilds, it has the air of a "reine
Fleissarbeit" (dict.leo.org: "a diligent but routine piece of work"). Of
course, any OS X 10.4 PPC specific bits and pieces would then have to
"behave well", too ... (the "symlinking approach" would probably make that
part rather straightforward).
P.P.S.:
Now that quite a few people are involved, wouldn't it make sense to try to
clean up that current BLAS configuration/setup code parts a bit? At least
between module_list.py, cython.py and the cvxopt spkg install, more or
less the same functionality is tripled. Possibly by moving all this to
setting (or taking over from the parent environment) "SAGE_BLAS_LIB",
"SAGE_CBLAS_LIB", "SAGE_ATLAS_LIB" or the like environment variables,
ensuring these are sanely set at both the start of a Sage build (prereq
spkg?!), as well as in the Sage environment at runtime (sage-shell?!), and
then in "module_list.py", "misc/cython.py", cvxopt spkg install, ...
simply referring to/using/relying on these env vars ... just letting the
thoughts flow, sorry :-)
P.P.P.S.:
Unfortunately, it took me so long to write this, that it this message
already mostly outdated (by comments 221, 222).
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10508#comment:223>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.