Plots.jl and CairoMakie not precompiling

General Usage
1

I can’t seem to get Pluto or CairoMakie to precompile, and I am not sure why. This is on a company computer so I am not sure if this is related to any firewall?

Other packages seem to precompile fine. Has anyone had an issue like this?

Below is an image of the first part of the error.

image
image1216×532 88 KB

Here is a small section of the error. I do see an “Access is denied”. I know my computer has limited access. I just want to know if it is due to something like that and if I can get it unblocked. Plots was working though a few weeks ago and then I ran pkg> up and now it is no longer working.

LoadError: InitError: could not load library "C:\Users\CMILLER\.julia\artifacts\1f72a7f113b35c1817654c313d81935b76aa38e1\bin\libxml2-2.dll"
Access is denied.
Stacktrace:
  [1] dlopen(s::String, flags::UInt32; throw_error::Bool)
    @ Base.Libc.Libdl .\libdl.jl:117
  [2] dlopen(s::String, flags::UInt32)
    @ Base.Libc.Libdl .\libdl.jl:116
  [3] macro expansion
    @ C:\Users\CMILLER\.julia\packages\JLLWrappers\pG9bm\src\products\library_generators.jl:63 [inlined]
  [4] __init__()
    @ XML2_jll C:\Users\CMILLER\.julia\packages\XML2_jll\Yk7IC\src\wrappers\x86_64-w64-mingw32.jl:12
  [5] run_module_init(mod::Module, i::Int64)
    @ Base .\loading.jl:1128
  [6] register_restored_modules(sv::Core.SimpleVector, pkg::Base.PkgId, path::String)
    @ Base .\loading.jl:1116
  [7] _include_from_serialized(pkg::Base.PkgId, path::String, ocachepath::String, depmods::Vector{Any})
    @ Base .\loading.jl:1061
  [8] _require_search_from_serialized(pkg::Base.PkgId, sourcepath::String, build_id::UInt128)
    @ Base .\loading.jl:1575
  [9] _require(pkg::Base.PkgId, env::String)
    @ Base .\loading.jl:1932
 [10] __require_prelocked(uuidkey::Base.PkgId, env::String)
    @ Base .\loading.jl:1806
 [11] #invoke_in_world#3
    @ Base .\essentials.jl:921 [inlined]
 [12] invoke_in_world
    @ Base .\essentials.jl:918 [inlined]
 [13] _require_prelocked(uuidkey::Base.PkgId, env::String)
    @ Base .\loading.jl:1797
 [14] macro expansion
    @ Base .\loading.jl:1784 [inlined]
 [15] macro expansion
    @ Base .\lock.jl:267 [inlined]
 [16] __require(into::Module, mod::Symbol)
    @ Base .\loading.jl:1747
 [17] #invoke_in_world#3
    @ Base .\essentials.jl:921 [inlined]
 [18] invoke_in_world
    @ Base .\essentials.jl:918 [inlined]
 [19] require(into::Module, mod::Symbol)
    @ Base .\loading.jl:1740
 [20] include(mod::Module, _path::String)
    @ Base .\Base.jl:495
 [21] top-level scope
    @ C:\Users\CMILLER\.julia\packages\JLLWrappers\pG9bm\src\toplevel_generators.jl:192
 [22] include
    @ Base .\Base.jl:495 [inlined]
 [23] include_package_for_output(pkg::Base.PkgId, input::String, depot_path::Vector{String}, dl_load_path::Vector{String}, load_path::Vector{String}, concrete_deps::Vector{Pair{Base.PkgId, UInt128}}, source::String)
    @ Base .\loading.jl:2216
 [24] top-level scope
    @ stdin:3
during initialization of module XML2_jll
in expression starting at C:\Users\CMILLER\.julia\packages\Gettext_jll\5wIPp\src\wrappers\x86_64-w64-mingw32-cxx11.jl:6
in expression starting at C:\Users\CMILLER\.julia\packages\Gettext_jll\5wIPp\src\Gettext_jll.jl:2
in expression starting at stdin:3
ERROR: LoadError: Failed to precompile Gettext_jll [78b55507-aeef-58d4-861c-77aaff3498b1] to "C:\\Users\\CMILLER\\.julia\\compiled\\v1.10\\Gettext_jll\\jl_8EB2.tmp".
2

I’m afraid you have been bitten by Permissions issues with artifacts on Windows in 1.10-rc1 (and betas) - Access is denied · Issue #52272 · JuliaLang/julia · GitHub
A pattern seems to take form in that this happens to Windows users with low privileges in theirs machines.

3

Is there anything I can do or any update coming? From looking through the issues, it looks like there may have been a workaround, but it was sort of hard to follow.

I really hope there is a solution coming. I am testing out julia (I will probably use it anyway), but I don’t think I can convince anyone at the company to use julia with these sorts of issues.

4

The workaround is delete the artifacts and reinstall the packages (same versions!) with Julia 1.9 which would add back the artifacts with the right permissions.

5

But I guess that a user with low privileges will not be able to apply that workaround.
This is an important issue that must be solved with a new Julia version.

1 Like
6

The workaround does not require admin rights.

7

But installing a new Julia version does (not 100% sure of this but that’s normally the case when using installers).

8

You are correct. I would have to get permission to install Julia 1.9 (and is that going to mess up VS Code using juliaup). That may not be too bad, but it is the reason I am still at 1.10.0 instead of the more recent versions.

I may try to do the 1.9 route, but how many artifact folders do I need to delete? Do I just delete all of them? It seems like a hassle going through each one.

9

Sorry, I’m being dumb. I had the same (permissions to install) problem in a computer classroom and workaround it by installing the Julia portable version that requires no installer, just unzip a bunch of files. Had no issues installing packages in it.

1 Like
10

If you’re not worried about download size you can just nuke the .julia/artifacts folder.

1 Like
11

I ended up nuking the .julia/artifacts folder and trying Julia 1.10.2. It ended up working!

I am not sure if this is 100% reproducible, since I unzipped the portable version in my downloads folder and installed the artifacts back by just pkg> add Plots (using julia.exe from downloads folder), and it precompiled. I then went through juliaup and downloaded Julia 1.10.2 and it precompiled again, but it is working now. I wish I could go back and just try juliaup, but I suspect it would have worked.

I also didn’t need permissions doing juliaup this time which is not what happened last time. Maybe the julia.exe file did not change from 1.10.0 to 1.10.2? I am not sure. I am just glad it is working.

I just wanted to document my process for those who may have the same issue!