OrdinaryDiffEqSymplecticRK: LoadError: UndefVarError: default_linear_interpolation not defined

[giordano]

Describe the bug 🐞

Can't precompile OrdinaryDiffEqSymplecticRK v1.2.0:

ERROR: LoadError: UndefVarError: `default_linear_interpolation` not defined
Stacktrace:
 [1] getproperty(x::Module, f::Symbol)
   @ Base ./Base.jl:31
 [2] top-level scope
   @ ~/.julia/packages/OrdinaryDiffEqSymplecticRK/8SXKX/src/algorithms.jl:47
 [3] include(mod::Module, _path::String)
   @ Base ./Base.jl:495
 [4] include(x::String)
   @ OrdinaryDiffEqSymplecticRK ~/.julia/packages/OrdinaryDiffEqSymplecticRK/8SXKX/src/OrdinaryDiffEqSymplecticRK.jl:1
 [5] top-level scope
   @ ~/.julia/packages/OrdinaryDiffEqSymplecticRK/8SXKX/src/OrdinaryDiffEqSymplecticRK.jl:22
 [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}}, sour
ce::String)
   @ Base ./loading.jl:2292
 [8] top-level scope
   @ stdin:4
in expression starting at /home/cceamgi/.julia/packages/OrdinaryDiffEqSymplecticRK/8SXKX/src/algorithms.jl:47
in expression starting at /home/cceamgi/.julia/packages/OrdinaryDiffEqSymplecticRK/8SXKX/src/OrdinaryDiffEqSymplecticRK.jl:1
in expression starting at stdin:4

Expected behavior

Being able to precompile the package

Minimal Reproducible Example 👇

Without MRE, we would only be able to help you to a limited extent, and attention to the issue would be limited. to know more about MRE refer to wikipedia and stackoverflow.

using Pkg
Pkg.add(name="OrdinaryDiffEqSymplecticRK", version="1.2.0")

Error & Stacktrace ⚠️

Stacktrace:
 [1] getproperty(x::Module, f::Symbol)
   @ Base ./Base.jl:31
 [2] top-level scope
   @ ~/.julia/packages/OrdinaryDiffEqSymplecticRK/8SXKX/src/algorithms.jl:47
 [3] include(mod::Module, _path::String)
   @ Base ./Base.jl:495
 [4] include(x::String)
   @ OrdinaryDiffEqSymplecticRK ~/.julia/packages/OrdinaryDiffEqSymplecticRK/8SXKX/src/OrdinaryDiffEqSymplecticRK.jl:1
 [5] top-level scope
   @ ~/.julia/packages/OrdinaryDiffEqSymplecticRK/8SXKX/src/OrdinaryDiffEqSymplecticRK.jl:22
 [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}}, sour
ce::String)
   @ Base ./loading.jl:2292
 [8] top-level scope
   @ stdin:4
in expression starting at /home/cceamgi/.julia/packages/OrdinaryDiffEqSymplecticRK/8SXKX/src/algorithms.jl:47
in expression starting at /home/cceamgi/.julia/packages/OrdinaryDiffEqSymplecticRK/8SXKX/src/OrdinaryDiffEqSymplecticRK.jl:1
in expression starting at stdin:4

Environment (please complete the following information):

• Output of using Pkg; Pkg.status()

(julia-ipu.jl) pkg> st -m OrdinaryDiffEqSymplecticRK OrdinaryDiffEq
Status `/tmp/jl_1jdQMV/julia-ipu.jl/Manifest.toml`
  [1dea7af3] OrdinaryDiffEq v6.91.0
⌃ [fa646aed] OrdinaryDiffEqSymplecticRK v1.2.0
Info Packages marked with ⌃ have new versions available and may be upgradable.

• Output of versioninfo()

julia> versioninfo()
Julia Version 1.10.8
Commit 4c16ff44be8 (2025-01-22 10:06 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 256 × AMD EPYC 7742 64-Core Processor
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-15.0.7 (ORCJIT, znver2)
Threads: 1 default, 0 interactive, 1 GC (on 256 virtual cores)

Additional context

I have a large environment with lots of packages and because of some cross dependencies I can't upgrade OrdinaryDiffEqSymplecticRK to v1.3.0, where I think this issue was fixed by 3c7197b. I think I'd need a v1.2.1 with that issue backported, because at the moment 1.2.0 is completely unusable

[JoshuaLampert]

See #2600.

[ChrisRackauckas]

I have a large environment with lots of packages and because of some cross dependencies I can't upgrade OrdinaryDiffEqSymplecticRK to v1.3.0, where I think this issue was fixed by 3c7197b. I think I'd need a v1.2.1 with that issue backported, because at the moment 1.2.0 is completely unusable

IIRC v1.3.0 just bumps the lower bounds to make this issue not possible? So that can't be a v1.2.1?