Precompiling Ipopt fails on unsupported platform and OpenSpecFun_jll

[artkuo]

After adding Ipopt, I get this error

julia> using Ipopt
[ Info: Precompiling Ipopt [b6b21f68-93f8-5de0-b562-5493be1d77c9]
ERROR: LoadError: ArgumentError: Platform `riscv64-linux-gnu-libgfortran5` is not an officially supported platform
Stacktrace:
 [1] parse(::Type{Base.BinaryPlatforms.Platform}, triplet::String; validate_strict::Bool)
   @ Base.BinaryPlatforms ./binaryplatforms.jl:753
 [2] parse(::Type{Base.BinaryPlatforms.Platform}, triplet::String)
   @ Base.BinaryPlatforms ./binaryplatforms.jl:671
 [3] (::OpenSpecFun_jll.var"#parse_wrapper_platform#1")(x::Any)
   @ OpenSpecFun_jll ~/.julia/packages/JLLWrappers/pG9bm/src/toplevel_generators.jl:113
 [4] (::OpenSpecFun_jll.var"#make_wrapper_dict#2"{OpenSpecFun_jll.var"#parse_wrapper_platform#1"})(dir::Any, x::Any)
   @ OpenSpecFun_jll ~/.julia/packages/JLLWrappers/pG9bm/src/toplevel_generators.jl:145
 [5] top-level scope
   @ ~/.julia/packages/JLLWrappers/pG9bm/src/toplevel_generators.jl:160
 [6] include
   @ ./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::String)
   @ Base ./loading.jl:2222
 [8] top-level scope
   @ stdin:3
in expression starting at /Users/artkuo/.julia/packages/OpenSpecFun_jll/4QIOW/src/OpenSpecFun_jll.jl:2
in expression starting at stdin:3
ERROR: LoadError: Failed to precompile OpenSpecFun_jll [efe28fd5-8261-553b-a9e1-b2916fc3738e] to "/Users/artkuo/.julia/compiled/v1.10/OpenSpecFun_jll/jl_l0nHz6".

So I reverted from the automatic OpenSpecFun_jll v0.5.6+0 with an older add [email protected] and it added v0.5.5+2. I removed and re-added Ipopt 1.7.1, and using now works fine. The riscv64-linux error is strange, because this is a Mac:

julia> versioninfo()
Julia Version 1.10.3
Commit 0b4590a5507 (2024-04-30 10:59 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: macOS (arm64-apple-darwin22.4.0)
  CPU: 10 × Apple M1 Pro
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-15.0.7 (ORCJIT, apple-m1)
Threads: 1 default, 0 interactive, 1 GC (on 8 virtual cores)

I'm not sure if the problem is Ipopt, but I didn't see an issues page for OpenSpecFun_jll.

[odow]

I'm not sure what error caused this, but it doesn't seem to be related to Ipopt.jl. I also can't reproduce this on my M1 Mac.

Did you do any previous package operations that got cancelled in some corrupt state?

Edit: I've asked about this on slack.

[odow]

The suggestion is just to run import Pkg; Pkg.update() and then restart Julia. It looks like the correct version of some packages were not loaded correctly.

[giordano]

https://discourse.julialang.org/t/dsp-jl-loading-error/124345/2

[artkuo]

Thanks for the suggestion. I tried doing Pkg.update() and restarted (maybe I neglected that earlier). Upon activating environment, I get the same error. Reverting to [email protected] again solves the issue. Actually, only sort of, because now I get intermittent WARNING: redefinition of constant fzf_jll.PATH associated with Revise. So I believe there is something mucked up with my base Julia install and will try to fix it. I agree this doesn't seem to be specific to Ipopt, so closing.

As a side note to @giordano, my manifest shows I was already on [email protected] even before this issue. However, there is something odd going on with riscv64 since it just doesn't make sense.

Thanks for the help both of you.

[giordano]

As a side note to @giordano, my manifest shows I was already on [email protected] even before this issue.

That' not what I said in the link: you're stacking multiple environments, and whatever version of JLLWrappers is loaded first in one of your environments that's the winning one. As an example:

(@v1.11) pkg> activate --temp
  Activating new project at `/var/folders/v2/hmy3kzgj4tb3xsy8qkltxd0r0000gn/T/jl_bIWIyX`

(jl_bIWIyX) pkg> add [email protected]
   Resolving package versions...
    Updating `/private/var/folders/v2/hmy3kzgj4tb3xsy8qkltxd0r0000gn/T/jl_bIWIyX/Project.toml`
⌃ [692b3bcd] + JLLWrappers v1.6.1
    Updating `/private/var/folders/v2/hmy3kzgj4tb3xsy8qkltxd0r0000gn/T/jl_bIWIyX/Manifest.toml`
⌃ [692b3bcd] + JLLWrappers v1.6.1
  [21216c6a] + Preferences v1.4.3
  [56f22d72] + Artifacts v1.11.0
  [ade2ca70] + Dates v1.11.0
  [de0858da] + Printf v1.11.0
  [fa267f1f] + TOML v1.0.3
  [4ec0a83e] + Unicode v1.11.0
        Info Packages marked with ⌃ have new versions available and may be upgradable.

julia> using JLLWrappers

(jl_bIWIyX) pkg> activate --temp
  Activating new project at `/var/folders/v2/hmy3kzgj4tb3xsy8qkltxd0r0000gn/T/jl_MmGxpz`

(jl_MmGxpz) pkg> add [email protected]
   Resolving package versions...
    Updating `/private/var/folders/v2/hmy3kzgj4tb3xsy8qkltxd0r0000gn/T/jl_MmGxpz/Project.toml`
  [692b3bcd] + JLLWrappers v1.7.0
    Updating `/private/var/folders/v2/hmy3kzgj4tb3xsy8qkltxd0r0000gn/T/jl_MmGxpz/Manifest.toml`
  [692b3bcd] + JLLWrappers v1.7.0
  [21216c6a] + Preferences v1.4.3
  [56f22d72] + Artifacts v1.11.0
  [ade2ca70] + Dates v1.11.0
  [de0858da] + Printf v1.11.0
  [fa267f1f] + TOML v1.0.3
  [4ec0a83e] + Unicode v1.11.0

(jl_MmGxpz) pkg> st
Status `/private/var/folders/v2/hmy3kzgj4tb3xsy8qkltxd0r0000gn/T/jl_MmGxpz/Project.toml`
  [692b3bcd] JLLWrappers v1.7.0

julia> using JLLWrappers

julia> pkgversion(JLLWrappers)
v"1.6.1"

The last environment I activate says I have JLLWrappers 1.7.0, but the package had actually been loaded before (perhaps indirectly through other packages) with a different version and that's what's actually being used.

I can't say this property of stacked environments of happily allowing incompatible packages is particularly nice, because you end up in situation where you have a version of package which shouldn't be there, and it seemingly isn't there, but it's coming from somewhere else.

[artkuo]

Thanks for the explanation, I believe that is the issue due to different versions in base and local environment. I updated to Julia 1.11 and instantiating there seemed to resolve it.