# Julia not using the most recent version of Gurobi

**URL:** https://discourse.julialang.org/t/julia-not-using-the-most-recent-version-of-gurobi/65539
**Category:** Optimization (Mathematical)
**Tags:** question, gurobi
**Created:** [July 30, 2021, 1:38am UTC](https://discourse.julialang.org/t/julia-not-using-the-most-recent-version-of-gurobi/65539 "2021-07-30T01:38:06Z")
**Posts on this page:** 11
**Page:** 1

<div class="post-metadata">

### Author: ![ZHEN\_LIN](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zhen_lin/32/27672_2.png) [@ZHEN\_LIN](https://discourse.julialang.org/u/ZHEN_LIN)
#### Post date: [July 30, 2021, 1:38am UTC](https://discourse.julialang.org/t/julia-not-using-the-most-recent-version-of-gurobi/65539/1 "2021-07-30T01:38:06Z")

</div>

I have been using Gurobi 9.0.1 in Julia with JuMP. Now I have installed Gurobi 9.1.2, but the output of Gurobi in Julia indicates that it is still using 9.0.1. How do I make it use the most recent version of Gurobi?

I checked `ENV["GUROBI_HOME"]` in Julia and it is pointing to Gurobi 9.1.2

By the way, after I installed Gurobi 9.1.2, I have not updated or rebulit my `Gurobi.jl` whose version is `Gurobi v0.9.3`. Do I need to re-do again something like `Pkg.build("Gurobi")` or reinstall it?

Thanks.

---

<div class="post-metadata">

### Author: ![leethargo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/leethargo/32/6004_2.png) [@leethargo](https://discourse.julialang.org/u/leethargo)
#### Post date: [July 30, 2021, 6:03am UTC](https://discourse.julialang.org/t/julia-not-using-the-most-recent-version-of-gurobi/65539/2 "2021-07-30T06:03:46Z")

</div>

> Do I need to re-do again something like `Pkg.build("Gurobi")` or reinstall it?

Yes, I think this should help. Looking at [Gurobi.jl/deps/build.jl](https://github.com/jump-dev/Gurobi.jl/blob/master/deps/build.jl), we can see that the `build` process stores a link to the shared library to be used by Gurobi.jl. Maybe the old `deps.jl` should be deleted as well, before running `build`.

---

<div class="post-metadata">

### Author: ![odow](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/odow/32/28685_2.png) [@odow](https://discourse.julialang.org/u/odow)
#### Post date: [July 30, 2021, 10:12am UTC](https://discourse.julialang.org/t/julia-not-using-the-most-recent-version-of-gurobi/65539/3 "2021-07-30T10:12:13Z")

</div>

If you update Gurobi, you need to re-run `Pkg.build`. No need to delete old files.

---

<div class="post-metadata">

### Author: ![ZHEN\_LIN](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zhen_lin/32/27672_2.png) [@ZHEN\_LIN](https://discourse.julialang.org/u/ZHEN_LIN)
#### Post date: [July 30, 2021, 10:45pm UTC](https://discourse.julialang.org/t/julia-not-using-the-most-recent-version-of-gurobi/65539/4 "2021-07-30T22:45:16Z")

</div>

Thank you.

If I want to change between different versions of Gurobi, do I just change the `ENV["GUROBI_HOME"]` to the corresponding Gurobi version I want to use, and then re-run `Pkg.build("Gurobi")`?

---

<div class="post-metadata">

### Author: ![odow](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/odow/32/28685_2.png) [@odow](https://discourse.julialang.org/u/odow)
#### Post date: [July 31, 2021, 12:49am UTC](https://discourse.julialang.org/t/julia-not-using-the-most-recent-version-of-gurobi/65539/5 "2021-07-31T00:49:25Z")

</div>

Yes

---

<div class="post-metadata">

### Author: ![lgo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lgo/32/48751_2.png) [@lgo](https://discourse.julialang.org/u/lgo)
#### Post date: [February 20, 2025, 9:55am UTC](https://discourse.julialang.org/t/julia-not-using-the-most-recent-version-of-gurobi/65539/6 "2025-02-20T09:55:03Z")

</div>

Sorry for bringing up this ancient thread, but I feel my issue does not deserve a new one. To fix a Gurobi issue discussed [here](https://support.gurobi.com/hc/en-us/community/posts/32772455327761-False-positive-on-second-order-cone-feasibility-problem), I need to switch from 12.0.0 to 12.0.1. `ENV["GUROBI_HOME"]` points to 12.0.1, and I did `Pkg.build("Gurobi")`, but checking the version, as described [here](https://stackoverflow.com/questions/73717371/how-to-determine-gurobi-or-solver-version-in-jump), I’m still on 12.0.0.

Is 12.0.1 just not supported yet, or is there another issue?

---

<div class="post-metadata">

### Author: ![odow](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/odow/32/28685_2.png) [@odow](https://discourse.julialang.org/u/odow)
#### Post date: [February 20, 2025, 10:58pm UTC](https://discourse.julialang.org/t/julia-not-using-the-most-recent-version-of-gurobi/65539/7 "2025-02-20T22:58:44Z")

</div>

Hi Leo, to opt-in to local installations, you know need to additionally set `ENV["GUROBI_JL_USE_GUROBI_JLL"] = "false"`.

See this part of the README [Gurobi.jl/README.md at master · jump-dev/Gurobi.jl · GitHub](https://github.com/jump-dev/Gurobi.jl/blob/master/README.md#manual-installation)

I’ll ~~see if we can~~ update the automatic binaries: [Add support for v12.0.1 by odow · Pull Request #33 · jump-dev/Gurobi\_jll.jl · GitHub](https://github.com/jump-dev/Gurobi_jll.jl/pull/33)

---

<div class="post-metadata">

### Author: ![odow](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/odow/32/28685_2.png) [@odow](https://discourse.julialang.org/u/odow)
#### Post date: [February 21, 2025, 2:35am UTC](https://discourse.julialang.org/t/julia-not-using-the-most-recent-version-of-gurobi/65539/8 "2025-02-21T02:35:46Z")

</div>

12.0.1 should be automatically installed if you update your packages. No need for `GUROBI_HOME`.

---

<div class="post-metadata">

### Author: ![lgo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lgo/32/48751_2.png) [@lgo](https://discourse.julialang.org/u/lgo)
#### Post date: [February 21, 2025, 12:58pm UTC](https://discourse.julialang.org/t/julia-not-using-the-most-recent-version-of-gurobi/65539/9 "2025-02-21T12:58:55Z")

</div>

Thanks Oscar! That worked for me.

---

<div class="post-metadata">

### Author: ![NiclasMattsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/niclasmattsson/32/21988_2.png) [@NiclasMattsson](https://discourse.julialang.org/u/NiclasMattsson)
#### Post date: [February 21, 2025, 1:27pm UTC](https://discourse.julialang.org/t/julia-not-using-the-most-recent-version-of-gurobi/65539/10 "2025-02-21T13:27:29Z")

</div>

Sorry to go a bit off topic, but is it technically possible without too much work to add support for hot-swapping solver versions without rebuilding and/or updating the packages? The reason I ask is that solver performance is model specific and doesn’t always strictly improve with new versions. So e.g. for some energy models we have in house Gurobi v10 consistently beat Gurobi v11. So it would be nice to be able to choose one version or the other at runtime.

Maybe this could work as a special solver option that gets intercepted by Gurobi.jl and reroutes to the correct binary, or something similar. Not asking the JuMP team to do it, but if you think it’s doable without knowing the full depth of JuMP internals then I might look into it myself.

---

<div class="post-metadata">

### Author: ![HSt](https://avatars.discourse-cdn.com/v4/letter/h/b38774/32.png) [@HSt](https://discourse.julialang.org/u/HSt)
#### Post date: [April 1, 2026, 3:24pm UTC](https://discourse.julialang.org/t/julia-not-using-the-most-recent-version-of-gurobi/65539/11 "2026-04-01T15:24:38Z")

</div>

Have you considered changed default parameters?  
Maybe try to list all parameters used by v10 on your problem and put them explicitly in v11 (or other newer v).

I have no idea of Gurobi internal changes per version, but with over 200 parameters my guess is that most code stays available with correct parametrization. (How parameters are guessed from problem structure is another obscurity…)

Some time ago I had an issue with a version jump and GurobiPy, as a default parameters was required in the new version, which was not provided by the interface. However, it was just about making it run, there was no interest / data in reproducing runtime performance for this project.

No idea if this comment helps, but at least testing it meets your “without too much work” requirement I guess.
