Skip to content

Support Gurobi 13 dynamic loading - #5272

Open
jaxor24 wants to merge 3 commits into
google:mainfrom
jaxor24:fix-mathopt-gurobi-13
Open

Support Gurobi 13 dynamic loading#5272
jaxor24 wants to merge 3 commits into
google:mainfrom
jaxor24:fix-mathopt-gurobi-13

Conversation

@jaxor24

@jaxor24 jaxor24 commented Jul 25, 2026

Copy link
Copy Markdown

Summary

Adds support for dynamically loading Gurobi 13.

Gurobi 13 no longer exports GRBcopyparams, which caused OR-Tools dynamic loading to fail before the solver could be used. This PR makes that symbol optional and adds a fallback implementation that copies non-default parameters explicitly.

Also included:

  • Adds Gurobi 13.0.0, 13.0.1, and 13.0.2 library search paths.
  • Ensures MathOpt Gurobi code loads the dynamic library before creating Gurobi environments/models.
  • Makes DynamicLibrary non-copyable and adds optional symbol lookup support.
  • Improves the Gurobi dynamic-library load error to report all attempted paths.
  • Updates gurobi_parse_header.py so optional symbols are generated with TryGetFunction.
  • Adds tests for parameter copying, fallback copying, and repeated dynamic-library loading.

Testing

bazelisk --nowindows_enable_symlinks build --jobs=2 //ortools/third_party_solvers:gurobi_environment //ortools/linear_solver:gurobi_util_test //ortools/linear_solver:linear_solver_gurobi //ortools/math_opt/solvers:gurobi_solver
bazelisk --nowindows_enable_symlinks test --jobs=2 //ortools/linear_solver:gurobi_util_test --test_output=errors

@Mizux

Mizux commented Jul 26, 2026

Copy link
Copy Markdown
Collaborator

our dev branch is main, stable only target the last release tag v9.15 which is based on v99bugfix branch which is not maintained...

@jaxor24
jaxor24 changed the base branch from stable to main July 26, 2026 21:28
@jaxor24
jaxor24 force-pushed the fix-mathopt-gurobi-13 branch from ebcf79e to ff8eee7 Compare July 26, 2026 21:49
@jaxor24

jaxor24 commented Jul 26, 2026

Copy link
Copy Markdown
Author

our dev branch is main, stable only target the last release tag v9.15 which is based on v99bugfix branch which is not maintained...

No problem - just rebased.

@jaxor24
jaxor24 force-pushed the fix-mathopt-gurobi-13 branch from ff8eee7 to cf1319e Compare July 30, 2026 00:30
7FM added a commit to esa-tu-darmstadt/Nailgun that referenced this pull request Jul 30, 2026
Highest Gurobi usable with or-tools 9.15 (Gurobi 13 dropped the
GRBcopyparams export that or-tools' loader CHECK-fails on; unmerged fix
google/or-tools#5272 — bump to 13.x once it ships in a release). 12.0.3
verified against the token server. Matches the longnail flake's pin.

nixpkgs deliberately NOT bumped: the eval env is not ready for what a
2026-07 snapshot drags in (cocotb 2.0, git >= 2.48 breaking init.sh).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
7FM added a commit to esa-tu-darmstadt/Shortnail that referenced this pull request Aug 3, 2026
`-schedule-lil solver=GUROBI` aborts every longnail-opt invocation that
reaches the MathOpt Gurobi backend:

  terminate called after throwing an instance of 'std::bad_function_call'
  #12 math_opt::GurobiNewPrimaryEnv(...)
  #24 schedulePARAMS(...)  ResourceSharing.cpp
  #29 ScheduleLIL::runOnOperation()

or-tools' MathOpt path never calls LoadGurobiDynamicLibrary
(google/or-tools#5079), so the GRB* std::function globals stay empty and
the first call throws — fatal, since CIRCT/longnail build -fno-exceptions.
This is independent of whether Gurobi is installed: the loader is not
invoked either way, so the `.ok()` fallback to HiGHS never gets a chance.
It bit the whole simulation suite plus the GUROBI-requesting tests under
test/ once scheduling moved from MPSolver (which probed availability with
MPSolver::SupportsProblemType, and degraded gracefully) to MathOpt.

nix/ortools_gurobi_loader.patch adds the missing load call and, as the
same load path needs it, makes DynamicLibrary non-copyable with a move
constructor — its implicit copy plus a dlclose'ing destructor unloads
libgurobi whenever the NoDestructor init lambda's return value is not
elided, which is every unoptimized build (we build Debug).

Wired into both build paths so they produce the same or-tools:
  * nix/ortools.nix gains a `patches` attribute
  * build_deps.sh injects a `patch -p1` ahead of the cmake line in
    circt/utils/get-or-tools.sh, which offers no hook of its own between
    unpacking the tarball and configuring it

Verified: the patch applies cleanly to a pristine v9.15 checkout of the
two files, RETURN_IF_ERROR is already in scope there, and
LoadGurobiDynamicLibrary is declared via the included
third_party_solvers/gurobi_environment.h.

Not version-guarded on purpose: an OR_TOOLS_VER bump fails loudly rather
than silently dropping the fix. The patch header records why upstream
PR google/or-tools#5272 cannot be used on 9.15.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@Mizux Mizux added this to the v10.0 milestone Aug 3, 2026
7FM added a commit to esa-tu-darmstadt/Nailgun that referenced this pull request Aug 3, 2026
Highest Gurobi usable with or-tools 9.15 (Gurobi 13 dropped the
GRBcopyparams export that or-tools' loader CHECK-fails on; unmerged fix
google/or-tools#5272 — bump to 13.x once it ships in a release). 12.0.3
verified against the token server. Matches the longnail flake's pin.

nixpkgs deliberately NOT bumped: the eval env is not ready for what a
2026-07 snapshot drags in (cocotb 2.0, git >= 2.48 breaking init.sh).

Co-Authored-By: Claude Fable 5 <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