Plots, InitError: UndefVarError: GR_jll not defined

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

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
  [1] __init__()
    @ GR.GRPreferences ~/.julia/packages/GR/jehu0/src/preferences.jl:64

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


This situation occurs due to some initial problem with loading GR_jll on this line:

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):

using Pkg
Pkg.activate(; temp = true)
import GR_jll

If that succeeds, then try the following.

using GR

If GR function works, then try adding Plots.jl

using Plots

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


@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.

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

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 and rework precompilation using `SnoopPrecompile` by t-bltg · Pull Request #4334 · JuliaPlots/Plots.jl · GitHub).

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?

@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?