# Plots, InitError: UndefVarError: GR\_jll not defined

**URL:** https://discourse.julialang.org/t/plots-initerror-undefvarerror-gr-jll-not-defined/102448
**Category:** General Usage
**Tags:** plot
**Created:** [August 3, 2023, 1:43pm UTC](https://discourse.julialang.org/t/plots-initerror-undefvarerror-gr-jll-not-defined/102448 "2023-08-03T13:43:16Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [August 3, 2023, 1:43pm UTC](https://discourse.julialang.org/t/plots-initerror-undefvarerror-gr-jll-not-defined/102448/1 "2023-08-03T13:43:16Z")

</div>

In some circumstances, a user may encounter the following error.

```julia
Failed to precompile Plots [91a5bcdd-55d7-5caf-9e0b-520d859cae80] to "~/.julia/compiled/v1.9/Plots/jl_crbDAx".
ERROR: LoadError: InitError: UndefVarError: `GR_jll` not defined
Stacktrace:
  [1] __init__ ()
    @ GR.GRPreferences ~/.julia/packages/GR/jehu0/src/preferences.jl:64

```

---

<div class="post-metadata">

### Author: ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [August 3, 2023, 1:43pm UTC](https://discourse.julialang.org/t/plots-initerror-undefvarerror-gr-jll-not-defined/102448/2 "2023-08-03T13:43:22Z")

</div>

A persistent error such as this may require the following command to force GR to recompile.

```julia
Base.compilecache(Base.identify_package("GR"))

```

This situation occurs due to some initial problem with loading GR\_jll on this line:

> <https://github.com/jheinen/GR.jl/blob/8ec015333c12f2c5728f4ec80a9d0ef54d26cdd4/src/preferences.jl#L6>

However, due to the surrounding `try`-`catch` the problem is ignored and compilation continues. Once the compilation succeeds, the issue may persist if Julia fails to recognize the need to invalidate the compile cache for GR.

If the above does not resolve the issue, first assess if there is a problem loading `GR_jll` with the following steps in a _fresh_ Julia session (restart Julia):

```julia
using Pkg
Pkg.activate(; temp = true)
Pkg.add("GR_jll")
import GR_jll

```

If that succeeds, then try the following.

```julia
Pkg.add("GR")
Base.compilecache(Base.identify_package("GR"))
using GR
GR.plot(rand(10))

```

If `GR` function works, then try adding Plots.jl

```julia
Pkg.add("Plots")
using Plots
Plots.plot(rand(10))

```

An alternate approach to using `Base.compilecache` would be to manually locate the files in `~/.julia/compiled/v1.9` for GR and remove them.

---

<div class="post-metadata">

### Author: ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [August 3, 2023, 2:00pm UTC](https://discourse.julialang.org/t/plots-initerror-undefvarerror-gr-jll-not-defined/102448/3 "2023-08-03T14:00:38Z")

</div>

@t-bltg @jheinen I believe there may be some room for improvement here. I cannot recall why there is a `try`-`catch` there to begin with.

Since we are not loading any librarys on `import GR_jll`, I am failing to imagine how `import GR_jll` can fail.

> <https://github.com/JuliaPackaging/Yggdrasil/blob/748b902ac4ef455501e01289b91ba7cc3188d04a/G/GR/build_tarballs.jl#L81-L84>

Perhaps the `try` here is just obsolute and we can remove it now?

---

<div class="post-metadata">

### Author: ![t-bltg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/t-bltg/32/25526_2.png) [@t-bltg](https://discourse.julialang.org/u/t-bltg)
#### Post date: [August 8, 2023, 11:11am UTC](https://discourse.julialang.org/t/plots-initerror-undefvarerror-gr-jll-not-defined/102448/4 "2023-08-08T11:11:29Z")

</div>

The `try / catch` is required since `ENV["GRDIR"]` can be set to point to a local GR build (and thus not provided through a `GR_jll`).  
This is imposed by the initial design of GR.jl (see [use `Preferences` by t-bltg · Pull Request #471 · jheinen/GR.jl · GitHub](https://github.com/jheinen/GR.jl/pull/471#issuecomment-1255900004) and [rework precompilation using `SnoopPrecompile` by t-bltg · Pull Request #4334 · JuliaPlots/Plots.jl · GitHub](https://github.com/JuliaPlots/Plots.jl/pull/4334#issuecomment-1255140011)).

---

<div class="post-metadata">

### Author: ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [August 9, 2023, 8:31am UTC](https://discourse.julialang.org/t/plots-initerror-undefvarerror-gr-jll-not-defined/102448/5 "2023-08-09T08:31:44Z")

</div>

Interesting. So if ENV[“GRDIR”] is set to a local build, `import GR_jll` will throw an error? Is that still the case now that we are not automatically loading any shared libraries via GR\_jll due to using `dont_dlopen=true` in the recipe?

> <https://github.com/JuliaPackaging/Yggdrasil/blob/ebf13fc0f139af3085da65ed3ceba952acf4395b/G/GR/build_tarballs.jl#L81-L84>

@jheinen, could you test if we still need that `try` - `catch` block in your environment?

If `GR_jll` still throws an error on import, I wonder it would make sense to develop a placeholder GR\_jll that is just empty?

I still wonder if we can insert something under `if binary == "GR_jll"` where `GR_jll` is presumed to be loaded to catch the condition where `GR_jll` is still undefined and then recommend the compile cache fix above?
