Jonathan Bober wrote:
> I got around to trying the latest OpenBLAS as Jean-Pierre Flori
> suggested, and the segfaults went away. (And all tests pass.) I guess
> that from my perspective this means I should open an "update to OpenBLAS
> 0.2.19" ticket. Or maybe it should be an "Update OpenBLAS to some
> working version" ticket. I don't know much about OpenBLAS, so I don't
> really know if 2.19 will work for me but will be broken for someone else.
Probably not a bad idea.
For me, building R currently segfaults in Sage 7.4.beta6 (with OpenBLAS)
while the same builds [with ATLAS] in Sage 7.3, both on a Piledriver
with FSF GCC 6.2 (configured to generate native code by default; without
any *FLAGS set by me).
OpenBLAS' testsuite though passes, and I recall to have seen similar in
building R in the past (quite long ago), but OTOH have no idea how I
fixed or worked around that previously.
I also noticed Sage's OpenBLAS package ("again") uselessly depends on
Sage's Python. And OpenBLAS' "configure" step doesn't seem to report
anything useful...
-leif
> (OpenBLAS 2.15, the current version, is from 11 months ago.)
>
> On Tue, Sep 27, 2016 at 9:48 AM, Jean-Pierre Flori <jpfl...@gmail.com
> <mailto:jpfl...@gmail.com>> wrote:
>
>
>
> On Monday, September 26, 2016 at 11:23:49 PM UTC+2, Jonathan Bober
> wrote:
>
> On Mon, Sep 26, 2016 at 10:10 PM, Jean-Pierre Flori
> <jpf...@gmail.com> wrote:
>
> I suspect that perhaps the copy I have the works is
> working because I built it as sage 7.3 at some point
> with SAGE_ATLAS_LIB set and then rebuilt it on the
> develop branch, which didn't get rid of the atlas
> symlinks that were already setup. So maybe it isn't
> actually using openBLAS.
>
> SAGE_ATLAS_LIB is just used for ATLAS, not OpenBlas.
>
>
> 1. So does that mean that on a clean build of the current
> development branch (or a recent enough beta) SAGE_ATLAS_LIB has,
> by default, no effect?
>
> Yes.
>
>
> 2. Either way, I suspect that doesn't necessarily mean that
> nothing strange happens if I build Sage 7.3 (with SAGE_ATLAS_LIB
> set) and then do a 'git checkout develop', then build again
> without first doing a distclean.
>
> Yes.
> I'm not exactly in what situation you end up when going this way
> because:
> * at 7.3, you ran configure/make which set up Atlas as the blas
> provider, build it and link everything to it
> * when checking out develop openblas became the default but I'm not
> sure this actually changed anything if configure was not run again
> before make... the best way to now for sure is to see if libraries
> depending on blas got rebuilt (in particular atlas and openblas do
> not provide binary compatible libraries, you have to link to libs
> with different names)
> Maybe Jeroen or Volker have a better idea of what situation you end
> up in.
>
> But if you run "make distclean" then you can be sure that openblas
> will be built and linked to...
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
