# What might be holding up a \_jll update?

**URL:** <https://discourse.julialang.org/t/what-might-be-holding-up-a-jll-update/139338>\
**Category:** General Usage\
**Tags:** gmt\
**Created:** [September 10, 2026, 2:47pm UTC](https://discourse.julialang.org/t/what-might-be-holding-up-a-jll-update/139338 "2026-09-10T14:47:13Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [September 10, 2026, 2:47pm UTC](https://discourse.julialang.org/t/what-might-be-holding-up-a-jll-update/139338/1 "2026-09-10T14:47:13Z")

</div>

Hi,  
In GMT.jl the GMT\_jll version is been hold by something to a version one year old.  
If I force the install with `] add GMT_jll` I see (checked in 3 different computers)

```julia-auto
st
...
[b68b8c3f] GMT_jll v6.6.0+0

```

but [newest version](https://github.com/JuliaBinaryWrappers/GMT_jll.jl) is v6.7.1 that dates from 4 days ago. I noticed that the [`build_tarballs.jl`](https://github.com/JuliaPackaging/Yggdrasil/blob/6eaacf5cac1176604ec4f6727778e755be035a3e/G/GMT/build_tarballs.jl) was depending on Julia 1.6. I did submit a new build with a compact update to Julia 1.10 but I’m still waiting for its merge and honestly I have many doubts that this will solve the issue.

So, my question is still, what may be holding the the GMT\_jll version into a version that is ~1 year old and, mainly, what can I do to fix this?

Thanks

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [September 11, 2026, 3:24pm UTC](https://discourse.julialang.org/t/what-might-be-holding-up-a-jll-update/139338/2 "2026-09-11T15:24:13Z")

</div>

I managed to half fix this situation. Apparently compat bounds in totally unrelated to `GMT_jll` (`GALD_jll` in this case) can hold the update. But things continue screwed still. Although a `[ up` (but `[up GMT` not) is able to update the `.julia\environments\v1.??`\Manifest.toml` to

```julia-auto
[[deps.GMT_jll]]
...
version = "6.7.1+0"

```

this keeps being totally ignored in further `[ up`and only deleting that file and running `Pkg.instantiate()` seems to finally solve the updating issue.

Bugs or wrong(?) procedures?

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [September 11, 2026, 3:42pm UTC](https://discourse.julialang.org/t/what-might-be-holding-up-a-jll-update/139338/3 "2026-09-11T15:42:19Z")

</div>

I mean, GMT\_jll has _lots_ of dependencies. Any other package that _also uses_ those dependencies, but has a stricter requirement could hold it back.

If I _only_ install GMT\_jll _and nothing else_ into a fresh environment, I get the latest version. But you need both the activated environment _and_ your global environment to not have those limiting packages added to it.

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [September 11, 2026, 4:01pm UTC](https://discourse.julialang.org/t/what-might-be-holding-up-a-jll-update/139338/4 "2026-09-11T16:01:27Z")

</div>

Well GMT has only 2 non-stdlib and non-\_jll: `Tables` & `PrecompileTools`  
plus these `*_jll`

GMT\_jll  
GDAL\_jll (only this one is a big dependency)  
PROJ\_jll  
Ghostscript\_jll  
LASzip\_jll  
Leptonica\_jll

of those only GMT depends on `GMT_jll`, nothing else depends on it. So I miss to understand why any other \_jll dependency may hold it

I also tried to update the `GMT_jll` alone, with mixed results. But one of my points is, the environment Manifest has now the latest version, but that is not the version that is use. Unless I delete the whole manifest and do a `Pkg.instantiate()`, which is something I would rather not have to tell students that they have to do.

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [September 12, 2026, 12:24am UTC](https://discourse.julialang.org/t/what-might-be-holding-up-a-jll-update/139338/5 "2026-09-12T00:24:18Z")

</div>

Assuming this is about v1.43.1 instead of v1.43.2 where this does happen in a fresh environment, `GMT@1.43.1` bounds `GDAL_jll = "302.1000,303.1100"` while `GMT_jll@6.7.1` bounds `GDAL_jll = "304.1200"`. Those bounds aren’t compatible to `Pkg`:

```julia-auto
(testgmt) pkg> st
Status `C:\Users\Benny\testgmt\Project.toml`
⌃ [5752ebe1] GMT v1.43.1
Info Packages marked with ⌃ have new versions available and may be upgradable.

(testgmt) pkg> add --preserve=direct GMT_jll@6.7.1
   Resolving package versions...
ERROR: Unsatisfiable requirements detected for package GDAL_jll [a7073274]:
 GDAL_jll [a7073274] log:
 ├─possible versions are: 3.0.3 - 305.1300.301 or uninstalled
 ├─restricted by julia compatibility requirements to versions: [3.0.3 - 3.2.1, 300.202.100 - 305.1300.301] or uninstalled
 ├─restricted by compatibility requirements with GMT [5752ebe1] to versions: 302.1000.0 - 303.1100.500
 │ └─GMT [5752ebe1] log:
 │ ├─possible versions are: 0.4.0 - 1.43.2 or uninstalled
 │ ├─restricted to versions * by project [486cb586], leaving only versions: 0.4.0 - 1.43.2
 │ │ └─project [486cb586] log:
 │ │ ├─possible versions are: 0.0.0 or uninstalled
 │ │ └─project [486cb586] is fixed to version 0.0.0
 │ └─restricted to versions 1.43.1 by an explicit requirement, leaving only versions: 1.43.1
 └─restricted by compatibility requirements with GMT_jll [b68b8c3f] to versions: 304.1200.0 - 304.1200.400 — no versions left
   └─GMT_jll [b68b8c3f] log:
     ├─possible versions are: 6.4.0 - 6.7.1 or uninstalled
     └─restricted to versions 6.7.1 by an explicit requirement, leaving only versions: 6.7.1

(testgmt) pkg> add GMT_jll
    Updating `C:\Users\Benny\testgmt\Project.toml`
⌃ [b68b8c3f] + GMT_jll v6.6.0+0
    Manifest No packages added to or removed from `C:\Users\Benny\testgmt\Manifest.toml`

```

v1.43.2 fixed that, but the rest of your environment stack can still obstruct it. What does `add --preserve=direct GMT_jll@6.7.1` say in that case?

> [@joa-quim](#):
>
> `[ up` (but `[up GMT` not) is able to update

I think the latter has the same rules as `Pkg.update` and defaults to not updating any of `GMT`’s dependencies.

```julia-auto
  If packages are given as positional arguments, the preserve argument can be used to control what other packages are
  allowed to update:

    • PRESERVE_ALL (default): Only allow pkg to update.
    • PRESERVE_DIRECT: Only allow pkg and indirect dependencies that are not a direct dependency in the project
       to update.
    • PRESERVE_NONE: Allow pkg and all its indirect dependencies to update.

```

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [September 12, 2026, 1:02am UTC](https://discourse.julialang.org/t/what-might-be-holding-up-a-jll-update/139338/6 "2026-09-12T01:02:26Z")

</div>

Thanks for looking into this. I don’t have much more computers where to test it, but in one with 1.43.2 and where the environments/manifest already has GMT\_jl 6.7.1

```julia-auto
(@v1.10) pkg> add --preserve=direct GMT_jll@6.7.1
    Updating registry at `C:\Users\j\.julia\registries\General.toml`
   Resolving package versions...
   Installed LLVMOpenMP_jll ─ v23.1.1+0
  Downloaded artifact: LLVMOpenMP
    Updating `C:\Users\j\.julia\environments\v1.10\Project.toml`
  [b68b8c3f] + GMT_jll v6.7.1+0
    Updating `C:\Users\j\.julia\environments\v1.10\Manifest.toml`
  [1d63c593] ↑ LLVMOpenMP_jll v22.1.7+0 ⇒ v23.1.1+0
Precompiling packages finished.
  3 dependencies successfully precompiled in 41 seconds. 98 already precompiled.

(@v1.10) pkg> st
Status `C:\Users\j\.julia\environments\v1.10\Project.toml`
  [5752ebe1] GMT v1.43.2
  [3c546f1b] InteractiveGMT v0.1.0 `C:\Users\j\.julia\dev\InteractiveGMT`
  [26020ff4] RemoteS v1.3.8
  [b68b8c3f] GMT_jll v6.7.1+0

julia> GMTver
v"6.6.0"

```

That last v"6.6.0" means the GMT\_jll was not updated. Only deleting the environments/…/Manifest.toml and do Pkg.instantiate() will solve it. I don’t find this nothing normal.

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [September 12, 2026, 1:13am UTC](https://discourse.julialang.org/t/what-might-be-holding-up-a-jll-update/139338/7 "2026-09-12T01:13:53Z")

</div>

What do you get with `GMT v1.43.2` and `GMTver`? If it prints

```julia-auto
v"6.8.0"

```

than all is OK. I got that in a Codespaces Julia 1.12

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [September 12, 2026, 5:04am UTC](https://discourse.julialang.org/t/what-might-be-holding-up-a-jll-update/139338/8 "2026-09-12T05:04:10Z")

</div>

> [@joa-quim](#):
>
> That last v"6.6.0" means the GMT\_jll was not updated.

Any chance you already loaded `GMT` before the `GMT_jll` update? The rest of the process would be stuck with the loaded version of `GMT_jll`. v1.12 warns about loaded packages, and I don’t remember if v1.10 did.

Anyways here’s `GMTver` for a couple of environments. I thought JLL versions matched their underlying library’s versions based on [this section](https://docs.binarybuilder.org/stable/building/#Version-number), was I mistaken? In any case, that’s not a `Pkg` version resolution problem anymore.

```julia-auto
(testgmt) pkg> st
Status `C:\Users\Benny\testgmt\Project.toml`
⌃ [5752ebe1] GMT v1.43.1
⌃ [b68b8c3f] GMT_jll v6.6.0+0
Info Packages marked with ⌃ have new versions available and may be upgradable.

julia> using GMT; GMTver
v"6.7.0"

```

```julia-auto
(testgmt) pkg> st
Status `C:\Users\Benny\testgmt\Project.toml`
  [5752ebe1] GMT v1.43.2
  [b68b8c3f] GMT_jll v6.7.1+0

julia> using GMT; GMTver
v"6.8.0"

```

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [September 12, 2026, 10:19am UTC](https://discourse.julialang.org/t/what-might-be-holding-up-a-jll-update/139338/9 "2026-09-12T10:19:01Z")

</div>

What you get is the correct behavior. I think I reproduced that in the Linux Codespaces machine, but not in at least two Win+Julia1.10 computers, where previous older GMT.jl versions were installed and I did a `] up`.  
Anyway, thanks for your trials.