mkl build error on Intel Mac

[AshtonSBradley]

using FFTW
FFTW.set_provider!("mkl")
exit()
using FFTW

errors

julia> err
1-element ExceptionStack:
The following 1 direct dependency failed to precompile:

FFTW [7a1cc6ca-52ef-59f5-83cd-3a7055c09341]

Failed to precompile FFTW [7a1cc6ca-52ef-59f5-83cd-3a7055c09341] to "/Users/abradley/.julia/compiled/v1.10/FFTW/jl_nSjeIh".
ERROR: LoadError: UndefVarError: `libmkl_rt_path` not defined
Stacktrace:
 [1] getproperty(x::Module, f::Symbol)
   @ Base ./Base.jl:31
 [2] top-level scope
   @ ~/.julia/packages/FFTW/ToovV/src/providers.jl:86
 [3] include(mod::Module, _path::String)
   @ Base ./Base.jl:495
 [4] include(x::String)
   @ FFTW ~/.julia/packages/FFTW/ToovV/src/FFTW.jl:1
 [5] top-level scope
   @ ~/.julia/packages/FFTW/ToovV/src/FFTW.jl:17
 [6] include
   @ Base ./Base.jl:495 [inlined]
 [7] include_package_for_output(pkg::Base.PkgId, input::String, depot_path::Vector{String}, dl_load_path::Vector{String}, load_path::Vector{String}, concrete_deps::Vector{Pair{Base.PkgId, UInt128}}, source::Nothing)
   @ Base ./loading.jl:2216
 [8] top-level scope
   @ stdin:3
in expression starting at /Users/abradley/.julia/packages/FFTW/ToovV/src/providers.jl:84
in expression starting at /Users/abradley/.julia/packages/FFTW/ToovV/src/FFTW.jl:1
in expression starting at stdin:
Stacktrace:
  [1] pkgerror(msg::String)
    @ Pkg.Types ~/.julia/juliaup/julia-1.10.0-rc2+0.x64.apple.darwin14/share/julia/stdlib/v1.10/Pkg/src/Types.jl:70
  [2] precompile(ctx::Pkg.Types.Context, pkgs::Vector{Pkg.Types.PackageSpec}; internal_call::Bool, strict::Bool, warn_loaded::Bool, already_instantiated::Bool, timing::Bool, _from_loading::Bool, kwargs::@Kwargs{io::Base.TTY})
    @ Pkg.API ~/.julia/juliaup/julia-1.10.0-rc2+0.x64.apple.darwin14/share/julia/stdlib/v1.10/Pkg/src/API.jl:1656
  [3] precompile(pkgs::Vector{Pkg.Types.PackageSpec}; io::Base.TTY, kwargs::@Kwargs{_from_loading::Bool})
    @ Pkg.API ~/.julia/juliaup/julia-1.10.0-rc2+0.x64.apple.darwin14/share/julia/stdlib/v1.10/Pkg/src/API.jl:159
  [4] precompile
    @ Pkg.API ~/.julia/juliaup/julia-1.10.0-rc2+0.x64.apple.darwin14/share/julia/stdlib/v1.10/Pkg/src/API.jl:147 [inlined]
  [5] #precompile#114
    @ Pkg.API ~/.julia/juliaup/julia-1.10.0-rc2+0.x64.apple.darwin14/share/julia/stdlib/v1.10/Pkg/src/API.jl:146 [inlined]
  [6] #invokelatest#2
    @ Base ./essentials.jl:889 [inlined]
  [7] invokelatest
    @ Base ./essentials.jl:884 [inlined]
  [8] _require(pkg::Base.PkgId, env::String)
    @ Base ./loading.jl:1957
  [9] __require_prelocked(uuidkey::Base.PkgId, env::String)
    @ Base ./loading.jl:1806
 [10] #invoke_in_world#3
    @ Base ./essentials.jl:921 [inlined]
 [11] invoke_in_world
    @ Base ./essentials.jl:918 [inlined]
 [12] _require_prelocked(uuidkey::Base.PkgId, env::String)
    @ Base ./loading.jl:1797
 [13] macro expansion
    @ Base ./loading.jl:1784 [inlined]
 [14] macro expansion
    @ Base ./lock.jl:267 [inlined]
 [15] __require(into::Module, mod::Symbol)
    @ Base ./loading.jl:1747
 [16] #invoke_in_world#3
    @ Base ./essentials.jl:921 [inlined]
 [17] invoke_in_world
    @ Base ./essentials.jl:918 [inlined]
 [18] require(into::Module, mod::Symbol)
    @ Base ./loading.jl:1740
 [19] eval
    @ ./boot.jl:385 [inlined]
 [20] eval
    @ ./Base.jl:88 [inlined]
 [21] repleval(m::Module, code::Expr, ::String)
    @ VSCodeServer ~/.vscode/extensions/julialang.language-julia-1.61.2/scripts/packages/VSCodeServer/src/repl.jl:229
 [22] (::VSCodeServer.var"#110#112"{Module, Expr, REPL.LineEditREPL, REPL.LineEdit.Prompt})()
    @ VSCodeServer ~/.vscode/extensions/julialang.language-julia-1.61.2/scripts/packages/VSCodeServer/src/repl.jl:192
 [23] with_logstate(f::Function, logstate::Any)
    @ Base.CoreLogging ./logging.jl:515
 [24] with_logger
    @ ./logging.jl:627 [inlined]
 [25] (::VSCodeServer.var"#109#111"{Module, Expr, REPL.LineEditREPL, REPL.LineEdit.Prompt})()
    @ VSCodeServer ~/.vscode/extensions/julialang.language-julia-1.61.2/scripts/packages/VSCodeServer/src/repl.jl:193
 [26] #invokelatest#2
    @ Base ./essentials.jl:887 [inlined]
 [27] invokelatest(::Any)
    @ Base ./essentials.jl:884
 [28] (::VSCodeServer.var"#62#63")()
    @ VSCodeServer ~/.vscode/extensions/julialang.language-julia-1.61.2/scripts/packages/VSCodeServer/src/eval.jl:34

with

julia> versioninfo()
Julia Version 1.10.0-rc2
Commit dbb9c46795b (2023-12-03 15:25 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: macOS (x86_64-apple-darwin22.4.0)
  CPU: 16 × Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-15.0.7 (ORCJIT, skylake)
  Threads: 11 on 16 virtual cores
Environment:
  JULIA_NUM_THREADS = 8
  JULIA_PKG_DEVDIR = /Users/abradley/Dropbox/Julia/Dev
  JULIA_EDITOR = code

and

(GPEvort) pkg> st
Status `~/Dropbox/Research/Projects/GPEvort/Project.toml`
  [adafc99b] CpuId v0.3.1
  [634d3b9d] DrWatson v2.13.0
  [7a1cc6ca] FFTW v1.7.2
  [0e44f5e4] Hwloc v2.2.0
  [033835bb] JLD2 v0.4.38
  [d96e819e] Parameters v0.12.3
⌃ [b688e990] VortexDistributions v0.3.1
  [37e2e46d] LinearAlgebra

[AshtonSBradley]

Fixed by downgrading to FFTW 1.7.1

[giordano]

#280 (comment)

[AshtonSBradley]

fine (although note the error message is different).

But the problem is: this leads to a lot of hard to diagnose problems in packages that depend on FFTW when switching machines if there is any code sync.

I would expect a robust default for the build process robust that doesn't require user interaction once setup. If you don't want to provide a built in way to switch to MKL then don't, and rather put a comment in the readme about how the user could do it manually. Then it is clearly on the user to sort out.

At present FFTW claims to provide it and then silently lets it fail.

[giordano]

fine (although note the error message is different).

Of course the error message is different, in #280 I initially misdiagnosed the problem: it wasn't that you were using MKL_jll 2024 without the x86_64 Darwin build (you had MKL_jll 2023), but that you were using IntelOpenMP_jll 2024 without x86_64 Darwin build, which means that libmkl could be loaded correctly but it couldn't find its openmp runtime. That was fixed by JuliaRegistries/General#96745 which forced MKL_jll to use a compatible version of IntelOpenMP_jll.

The error you're getting now is that you can't load libmkl, because that one doesn't exist at all in MKL_jll 2024.

But the problem is: this leads to a lot of hard to diagnose problems in packages that depend on FFTW when switching machines if there is any code sync.

You're literally using platform-dependent code, which is outside of our control since MKL is a proprietary binary library built exclusively by Intel.

I would expect a robust default for the build process robust that doesn't require user interaction once setup. If you don't want to provide a built in way to switch to MKL then don't, and rather put a comment in the readme about how the user could do it manually. Then it is clearly on the user to sort out.

I mean, you're changing the default fft backend, that would work on any platform. If you're opting into using MKL maybe you should verify whether that actually exists for your platform. I'm missing what's your point.

That said, #278 tries to automatically fallback on an existing backend if the user asks for a non existing one (except the current implementation would fail with MKL 2024).

[AshtonSBradley]

fine (although note the error message is different).

Of course the error message is different, in #280 I initially misdiagnosed the problem: it wasn't that you were using MKL_jll 2024 without the x86_64 Darwin build (you had MKL_jll 2023), but that you were using IntelOpenMP_jll 2024 without x86_64 Darwin build, which means that libmkl could be loaded correctly but it couldn't find its openmp runtime. That was fixed by JuliaRegistries/General#96745 which forced MKL_jll to use a compatible version of IntelOpenMP_jll.

The error you're getting now is that you can't load libmkl, because that one doesn't exist at all in MKL_jll 2024.

But the problem is: this leads to a lot of hard to diagnose problems in packages that depend on FFTW when switching machines if there is any code sync.

You're literally using platform-dependent code, which is outside of our control since MKL is a proprietary binary library built exclusively by Intel.

I would expect a robust default for the build process robust that doesn't require user interaction once setup. If you don't want to provide a built in way to switch to MKL then don't, and rather put a comment in the readme about how the user could do it manually. Then it is clearly on the user to sort out.

I mean, you're changing the default fft backend, that would work on any platform. If you're opting into using MKL maybe you should verify whether that actually exists for your platform. I'm missing what's your point.

That said, #278 tries to automatically fallback on an existing backend if the user asks for a non existing one (except the current implementation would fail with MKL 2024).

Yes, that is all true. However, I have come to expect a high standard of robustness from FFTW with respect to the interface presented to the user. If this is no longer the case, users will fall into two categories 1) those who understand the build system sufficiently to readily diagnose such issues (e.g. yourself); 2) those who are new users, or users who just want to get the most performance without knowing build details and expect that if a package provides a mechanism for install, then it should work. The latter will find this a rough edge requiring extra debugging to sort out: which MKL is the relevant one? Do I install MKL.jl? How do I know specifically 2024 is not supported without posting an issue here?

Judging by #278 I would suggest that a slightly more informative entry in the FFTW.jl readme regarding MKL is needed at the least, if we are entering an era of incomplete platform coverage.

[giordano]

if we are entering an era of incomplete platform coverage.

MKL has never been available to all platforms supported by Julia, and again, you're opting into it. If you have any concerns with the availability of MKL direct them to Intel.