Closed jishnub closed 2 years ago
This is from here: https://github.com/JuliaPy/PyCall.jl/blob/5d227fc23fda631783a68c9ff1c6aff47200978e/src/numpy.jl#L67
Hopefully, this warning can just be removed in Julia 1.7, since I think #443 may finally be fixed by @staticfloat's new libtrampoline
magic?
Mmm, it's unclear to me what the root cause of #443 is; is it that Julia configures MKL to be 64-bit and Numpy expects it to be 32-bit? If so, I guess someone needs to experiment with whether it's possible to load MKL as 32-bit and 64-bit at the same time with LBT.
is it that Julia configures MKL to be 64-bit and Numpy expects it to be 32-bit
Yes.
It's why we were bugging Intel about getting us an ILP64 version of MKL with prefixed symbols, as you'll recall. (Are we able to use that yet?)
Should we at least replace the BLAS.vendor()
call with something like any(contains("mkl"), getfield.(BLAS.get_config().loaded_libs, :libname))
to avoid the deprecation message before this is checked / worked out more carefully?
It would be good if the deprecation warning could be fixed (possibly as suggested by @carstenbauer) since the deprecation warnings break e.g. the doctests in PythonOT (https://github.com/JuliaOptimalTransport/PythonOT.jl/pull/18).
I see the following warning on Julia 1.7 on using
PyPlot
(which seems to usePyCall
internally):Sorry I don't have a repro immediately as the warning doesn't tell me where in my code this is happening. However this is clearly arising because
BLAS.vendor
is deprecated.