Skip to content

Cap ODEInterface to 0.4.8 to fix Julia 1.12+ solver loading#109

Draft
ChrisRackauckas-Claude wants to merge 3 commits into
SciML:masterfrom
ChrisRackauckas-Claude:fix-julia-1.12-odeinterface-load
Draft

Cap ODEInterface to 0.4.8 to fix Julia 1.12+ solver loading#109
ChrisRackauckas-Claude wants to merge 3 commits into
SciML:masterfrom
ChrisRackauckas-Claude:fix-julia-1.12-odeinterface-load

Conversation

@ChrisRackauckas-Claude

@ChrisRackauckas-Claude ChrisRackauckas-Claude commented Jun 20, 2026

Copy link
Copy Markdown
Contributor

Problem

The tests / Core (julia 1) and tests / Core (julia pre) jobs fail on master with:

AssertionError: (dlSolversInfo[dlname]).error === nothing
caused by: UndefVarError(:ODEInterface_jll, ..., ODEInterface)

in ODEInterface/DLSolvers.jl (getAllMethodPtrs -> loadODESolvers), which errors Core/algorithm_tests.jl at the first solve(prob, dopri5(), ...). The Core (julia lts) / 1.10 job is unaffected and stays green.

Root cause

ODEInterface 0.5.0 (the only registered 0.5.x) has a Julia 1.12+ incompatibility. loadODESolvers() runs @eval ODEInterface begin using ODEInterface_jll end and then, in the same call frame, accesses the ODEInterface_jll global via getproperty. Under Julia 1.12's stricter binding-partition / world-age semantics, the binding created by using is only visible in a newer world age, so the in-frame access raises UndefVarError(:ODEInterface_jll). Every solver then records a load error and getAllMethodPtrs throws SolverODEnotLoaded. Julia 1.10 had more permissive binding visibility, so it stayed green.

This was reproduced locally on Julia 1.12.6 (a bare using ODEInterface; loadODESolvers() yields dopri5 error => UndefVarError(:ODEInterface_jll)).

Fix

The upstream fix (luchr/ODEInterface.jl#36, merged, tagged v0.5.1) switches to import ODEInterface_jll + @eval getproperty(...) and resolves it — but v0.5.1 is still not registered in General, so it cannot be selected via compat.

As the last working registered version, ODEInterface 0.4.8 uses the older local-gfortran build path (no ODEInterface_jll), which loads correctly on Julia 1.12/1.13. This PR caps ODEInterface = "0.4.8".

Follow-up: gfortran for the 0.4.8 source build

Capping to 0.4.8 reintroduces 0.4.8's behaviour of compiling the Fortran solvers from source in deps/build.jl. On a runner without gfortran that build hard-errors with Currently only gfortran is supported., which broke the tests / QA (julia lts) job (the julia 1 runner happened to have gfortran, lts did not). This PR therefore also passes apt-packages: "gfortran" to the grouped-tests.yml workflow, so every test job installs gfortran before building/testing. (When apt-packages is set the workflow runs on ubuntu-24.04 instead of ubuntu-latest, as intended.)

When ODEInterface 0.5.1 is registered, the cap can be relaxed back to 0.5 (>= 0.5.1), the jll-based path restored, and the apt-packages: gfortran line removed.

Verification (local)

  • ODEInterface 0.4.8 + gfortran, Julia 1.10.11 lts (the failing QA job): ODEInterface resolves to 0.4.8, the gfortran-built solvers load, a dopri5() solve returns Success, and the QA suite passes (Aqua 7 pass + 1 pre-existing @test_broken, JET 1 pre-existing @test_broken).
  • GROUP=Core Julia 1.12.6 (originally failing Core): all Core test files pass, Core/algorithm_tests.jl runs all solve calls without error.
  • GROUP=Core Julia 1.10.11 lts: all Core test files pass — no regression.

Please ignore until reviewed by @ChrisRackauckas

ChrisRackauckas and others added 3 commits June 20, 2026 08:14
ODEInterface 0.5.0 (the only registered 0.5.x) fails to load its solver
libraries on Julia 1.12 and 1.13. `loadODESolvers()` does
`@eval ODEInterface begin using ODEInterface_jll end` and then, within the
same call frame, accesses the `ODEInterface_jll` global via `getproperty`.
Under Julia 1.12's stricter binding-partition / world-age semantics the
binding created by the `using` is only visible in a newer world age, so the
in-frame access raises `UndefVarError(:ODEInterface_jll)`. All solvers then
report a load error and `getAllMethodPtrs` throws `SolverODEnotLoaded`,
erroring Core/algorithm_tests.jl on the `julia 1` and `julia pre` CI jobs
(lts/1.10 was unaffected and stayed green).

The upstream fix (luchr/ODEInterface.jl PR SciML#36, tagged v0.5.1) switches to
`import ODEInterface_jll` and `@eval getproperty(...)`, but v0.5.1 is not yet
registered in General, so it cannot be selected by compat. ODEInterface
0.4.8 uses the older local gfortran build path, which loads correctly on
Julia 1.12/1.13, so cap to it as the last working registered version.

Verified locally: GROUP=Core `Pkg.test` passes on both Julia 1.12.6 and
1.10.11 (all Core test files green, exit 0). When ODEInterface 0.5.1 is
registered, this cap can be relaxed back to allow 0.5.1+.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Capping ODEInterface to 0.4.8 (to dodge the 0.5.0 Julia-1.12 _jll load
bug) reintroduces 0.4.8's gfortran source build in deps/build.jl. On
runners without gfortran the build errors with "Currently only gfortran
is supported", which broke the QA (julia lts) job. Pass apt-packages:
"gfortran" to the grouped-tests workflow so every test job has gfortran
before building/testing.

Verified locally on Julia 1.10: ODEInterface resolves to 0.4.8, the
gfortran-built solvers load, a dopri5() solve returns Success, and the
QA suite passes (Aqua 7 pass + pre-existing broken, JET pre-existing
broken).

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Downgrade job also builds ODEInterface 0.4.8 from source (gfortran),
which intermittently fails on runners lacking gfortran. Pass
apt-packages: "gfortran" to downgrade.yml for the same reason as the
main Tests workflow.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants