Workaround for julia compiled with MKL?

[Djoop]

I know that there are issues when both Julia and python use MKL (#100, #165, https://github.com/JuliaPy/PyCall.jl/issues/443 ). I'm only using python for PyPlot, so using MKL is not critical, I thought I could just as a workaround link python libraries to openblas to avoid the problem. I tried ENV["PYTHON"]=""; Pkg.build("PyCall") (https://github.com/JuliaPy/PyPlot.jl/issues/165#issuecomment-240516554), but it was still using MKL. So I manually installed nomkl in a clean environment:

julia> Conda.add("nomkl")

Now the packages indeed do not rely on MKL, e.g. for numpy:

julia> Pkg.build("PyCall")
julia> using PyCall
julia> np = pyimport("numpy")
julia> np.show_config()
lapack_opt_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/home/UNAME/.conda/envs/nomkl/lib']
    define_macros = [('HAVE_CBLAS', None)]
    language = c
blas_opt_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/home/UNAME/.conda/envs/nomkl/lib']
    define_macros = [('HAVE_CBLAS', None)]
    language = c
openblas_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/home/UNAME/.conda/envs/nomkl/lib']
    define_macros = [('HAVE_CBLAS', None)]
    language = c
blis_info:
  NOT AVAILABLE
openblas_lapack_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/home/UNAME/.conda/envs/nomkl/lib']
    define_macros = [('HAVE_CBLAS', None)]
    language = c
lapack_mkl_info:
  NOT AVAILABLE
blas_mkl_info:
  NOT AVAILABLE

but I still get a segfault when I try to use PyPlot:

julia> plot([1,2,3])
signal (11): Erreur de segmentation
in expression starting at no file:0
[1]    20255 segmentation fault (core dumped)  julia

Is it expected? Any idea how to set up with Conda an environment that can be used for PyPlot when julia is compiled with MKL (well, I guess that's the issue, but maybe there is another problem)? Plotting works correctly when calling python directly.

For reference:

julia> versioninfo()
Julia Version 1.1.0
Commit 80516ca202* (2019-01-21 21:24 UTC)
Platform Info:
  OS: Linux (x86_64-redhat-linux)
  CPU: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.1 (ORCJIT, skylake)

[stevengj]

The problem is that NumPy still links OpenBLAS with the same function names as MKL, because both of them implement the same BLAS interface (e.g. functions like dgemm), so they still conflict.

(In contrast, when Julia is linked with 64-bit OpenBLAS, it links a special version with "mangled" symbols that don't conflict with other BLAS libraries.)

In short, Julia linked with the 64-bit MKL is basically unusable with numpy.

[cauachagas]

I have Julia compiled from the source with MKL (Manjaro Linux). I solved the problem using a non-iterative backend for matplotlib.

In ~/.bashrc

# export MPLBACKEND=WebAgg # works with REPL, But if you move the pointer over the picture it will break
export MPLBACKEND="module://gr.matplotlib.backend_gr"

Now in Julia