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.