GKS: svgplugin.dll: can't load library, error 126 (0x7e)

[mkitti]

After JuliaPackaging/Yggdrasil#5784, I am encountering this issue on Windows with GR_jll v0.69.1+1:

GKS: svgplugin.dll: can't load library, error 126 (0x7e)
ERROR: SystemError: opening file "...\\jl_ViZ8T6pmd8.svg": No such file or directory

I can resolve by one of the following.

1. Downgrading GR_jll to v0.69.1+0

] add GR_jll#fc933dae4a54c49707193e2dcc7df1e5ef201cab

using GR_JLL
Libdl.dlopen(joinpath(dirname(GR.GRPreferences.GR_jll.libGR_path), "svgplugin"))

I'm adding the later to #483

[mkitti]

Resolved in ea529f5 . With dont_dlopen in GR_jll, we need to build GR_jll.LIBPATH ourselves.

[t-bltg]

Does this fix JuliaPackaging/Yggdrasil#5784 (comment) ?
Maybe we can remove PATH on windows since LIBPATH is adjusted...

[t-bltg]

@jheinen, for the next release of GR.jl, it'd be cautious to bump to 0.70.0, since the recent changes might break Plots.
This would allow us to test Plots ci before accepting the potentially breaking GR changes.

[jheinen]

Due to illness I am currently in the home office and do not have the possibility to test Windows systems. Hopefully, I can check it on Monday ...

[mkitti]

Does this fix JuliaPackaging/Yggdrasil#5784 (comment) ?
Maybe we can remove PATH on windows since LIBPATH is adjusted...

I suspect that we can. Do you know what the original issue was?

[t-bltg]

Do you know what the original issue was

From what I recall, this occurred when saving figures, and this involved svgplugin.dll for sure.

[t-bltg]

Ha, that might be related to vscode, JuliaPlots/Plots.jl#4375 (comment), it'll be great to confirm that GR#master (and also without PATH set) works on vscode on windows.
Afaik, we can't test vscode in ci (especially the embedded display mechanism of Plots in it), and this caused a lot end users troubles in Plots 1.35.

[mkitti]

Let me recapitulate from the top where the issue is with the yanked GR_jll and what the solution is. I believe there was also a defect on the system binary side.

Yanked GR_jll, v0.69.1+1 issue

GKS loads plugins dynamically. For example, here is where the svgplugin is loaded.
https://github.com/sciapp/gr/blob/9aa4f55f75101b76ba8e4406b78601e410642cc6/lib/gks/plugin.c#L247-L248

Thus we need to supply a library path.

The change to Yggdrasil's build_tarballs.jl for GR_jll passed the keyword dont_dlopen. This results in JuliaBinaryWrappers/GR_jll.jl@acb9ac8 (GR_jll v0.69.1+1) where nothing is passed as the third argument to JLLWrappers.@init_library_product.

Examining JLLWrappers.@init_library_product, setting the third argument dlopen_flags to nothing disables two statements: 1) dlopen and 2) push!(LIBPATH_list, dirname($(path_name))).
https://github.com/JuliaPackaging/JLLWrappers.jl/blob/f6f6abe972085c08072f5d61df1cf7e4746da84b/src/products/library_generators.jl#L62-L65

Disabling the push! call results in the problem. That in turn interferes with the proper construction of GR_jll.LIBPATH:
https://cs.github.com/JuliaPackaging/JLLWrappers.jl/blob/f6f6abe972085c08072f5d61df1cf7e4746da84b/src/wrapper_generators.jl?q=generate_init_footer#L51
GR_jll.LIBPATH[] will not contain the artifact path for libGR.

This propagates through to GRPreferences.libpath[]:

GR.jl/src/preferences.jl

Line 58 in 38cb1c8

libpath[] = GR_jll.LIBPATH[]

That in turn prevents the proper library path from being pushed into the PATH, DYLD_FALLBACK_LIBRARY_PATH, and GKS_QT environment variables.

https://cs.github.com/jheinen/GR.jl/blob/8b18b19a29e1a8fd0977e8000daa135939680f2e/src/GR.jl#L325

GR.jl/src/funcptrs.jl

Lines 36 to 43 in 8b18b19

	lp = GRPreferences.libpath[]
	if Sys.iswindows()
	ENV["PATH"] = join((lp, get(ENV, "PATH", "")), ';')
	@debug "`windows`: set library search path to" ENV["PATH"]
	elseif Sys.isapple()
	ENV["DYLD_FALLBACK_LIBRARY_PATH"] = join((lp, get(ENV, "DYLD_FALLBACK_LIBRARY_PATH", "")), ':')
	@debug "`macOS`: set fallback library search path to" ENV["DYLD_FALLBACK_LIBRARY_PATH"]
	end

Solution for GR_jll, v0.69.1+1

To compensate for the loss of LIBPATH building by the JLLWappers resulting from dont_dlopen, we need to build the LIBPATH ourselves on GRPreferences.__init__:
This was implemented in ea529f5#diff-2f56fb4df7441bc075aeb66f5ba5dab42395cfe73bb618c97d3b894cc280cf8eR59-R65

GR.jl/src/preferences.jl

Lines 59 to 65 in ea529f5

	# Because GR_jll does not dlopen as of 0.69.1+1, we need to append
	# the LIBPATH_list similar to JLLWrappers.@init_library_product
	push!(GR_jll.LIBPATH_list, dirname(GR_jll.libGR))
	# Recompute LIBPATH similar to JLLWrappers.@generate_init_footer
	unique!(GR_jll.LIBPATH_list)
	pathsep = GR_jll.JLLWrappers.pathsep
	GR_jll.LIBPATH[] = join(vcat(GR_jll.LIBPATH_list, Base.invokelatest(GR_jll.JLLWrappers.get_julia_libpaths))::Vector{String}, pathsep)

System binary issue

When binary == "system", there was a second issue. GRPreferences.libpath[] was set to joinpath(grdir[], "lib") . While this is correct on non-Windows systems, it should be joinpath(grdir[], "bin") on Windows.

GR.jl/src/preferences.jl

Line 66 in 6fc46ea

libpath[] = joinpath(grdir[], "lib")

Solution for System binary issue

The switch between lib and bin is already implemented in the GRPreferences.lib_path:

GR.jl/src/preferences.jl

Lines 25 to 30 in ea529f5

	lib_path(grdir::AbstractString, lib::AbstractString) =
	if Sys.iswindows()
	joinpath(grdir, "bin", lib)
	else
	joinpath(grdir, "lib", lib)
	end

The fix was implemented in 38cb1c8 by reusing the lib_path function.

GR.jl/src/preferences.jl

Line 66 in 38cb1c8

libpath[] = lib_path(grdir[], "")

[mkitti]

Mocking ijulia, atom, pluto, and vscode for testing

The detection mechanisms for determine if we are using an IDE or notebook is located in the following functions.

GR.jl/src/GR.jl

Lines 250 to 253 in 7286144

	isijulia() = isdefined(Main, :IJulia) && Main.IJulia isa Module && isdefined(Main.IJulia, :clear_output)
	isatom() = isdefined(Main, :Atom) && Main.Atom isa Module && Main.Atom.isconnected() && (isdefined(Main.Atom, :PlotPaneEnabled) ? Main.Atom.PlotPaneEnabled[] : true)
	ispluto() = isdefined(Main, :PlutoRunner) && Main.PlutoRunner isa Module
	isvscode() = isdefined(Main, :VSCodeServer) && Main.VSCodeServer isa Module && (isdefined(Main.VSCodeServer, :PLOT_PANE_ENABLED) ? Main.VSCodeServer.PLOT_PANE_ENABLED[] : true)

Thus, we can mock these environments by creating fake modules with certain symbols in them.

That will engage the embedded environment clause in GR.init().

GR.jl/src/GR.jl

Lines 316 to 321 in 7286144

	elseif isijulia() || ispluto() || isvscode() || isatom()
	mime_type[] = "svg"
	file_path[] = tempname() * ".svg"
	ENV["GKSwstype"] = "svg"
	ENV["GKS_FILEPATH"] = file_path[]
	@debug "Found an embedded environment" mime_type[] file_path[] ENV["GKSwstype"] ENV["GKS_FILEPATH"]

[mkitti]

Fixed in v0.70.0