OK, thanks, I guess it's fine as long as the default is OpenBLAS.
BTW, it would be very useful to build with USE_BLAS64=1
OPENBLAS_SYMBOLSUFFIX=64_ to use an ILP64 BLAS. Without this, packages
using BinaryBuilder/BinaryProvider which call BLAS won't install. This
affects notably Arpack.jl, which
Control: tag -1 +pending -wontfix
Hi Milan,
Things have changed a bit since I submitted this bug.
The 1.0.1-1 package waiting in NEW queue is linked against libblas.so.3
(which is a symlink pointing to openblas). The dependency of the
resulting package can be satisfied by installing any package
I second this (and I'm sure this reflects the opinion of upstream in
general). It's really important that after installing the julia package
one gets the same performance as with official upstream binaries. It's
a trap to use the Netlib reference BLAS/LAPACK by default, which is
known to be
Package: julia
Version: 0.7.0-1
Severity: wishlist
A user suggested that we build julia against libblas.so.3 instead
of openblas, as said here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903879#10
> The current version of gimp is incompatible with openblas (#903514).
>
> julia and
4 matches
Mail list logo
