-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange "missing from cache"/"does not support precompilation"/... errors #52132
Comments
Does this reproduce on master? |
Not sure about master, but I see the same on 1.10rc. |
1.9.4 or master would be helpful |
1.9.4 same |
Any ideas why these messages would appear?.. |
From a slack discussion (@lassepe), these warnings/errors seem to occur when |
Any updates on this?.. Everything works, but big "errors"/warnings look scary to users (: |
Do you see this on 1.10.0 & master? If so please share the output on those |
(I can repro this on 1.10) I wonder if this could be related to all the method overwrites in AccessorsExtra:
which causes loading the AccessorsExtra package to fail at precompilation and as a fallback it loads without a precomple cache (see #52214) which then reloads the extensions etc. AcessorsExtra has stuff like: # some piracy:
Accessors.IndexLens(::Tuple{Elements}) = Elements()
Accessors.IndexLens(::Tuple{Properties}) = Properties()
Accessors._shortstring(prev, o::Elements) = "$prev[∗]"
...
# some piracy - should upstream:
getall(obj::AbstractDict, ::Elements) = collect(obj)
getall(obj::AbstractSet, ::Elements) = collect(obj) Edit: I removed what I think are all method overwrites and it does not seem to fix it what I can see. |
This repros with only Accessors for me (also, does not require Pkg.precompile to repro):
|
I wonder if making multiple extensions that each depend on a different packages in the sysimage is racy |
I just updated to 1.10.0 (from 1.8.5) and have started seeing this, and it seems to be causing sysimage builds with PackageCompiler to fail in our pipeline with the error: ERROR: Method overwriting is not permitted during Module precompilation. Use `__precompile__(false)` to opt-out of precompilation.
ERROR: LoadError: Declaring __precompile__(false) is not allowed in files that are being precompiled. Trying to see if I can make an MWE. |
Yes, same output on 1.10.
Nope, not related.
Recently we moved to "make everything a weakdep when possible" in Accessors, making this issue manifest for that package alone as well. |
FYI we made things stong deps again in Accessors, to circumvent this issue. People need Accessors.jl v0.1.34 to reproduce. |
I don't think this is related to the issue here. |
Just a bit of an update here. We (me and @IanButterworth) think this issue has to do with adding extensions to packages that are in the sysimage (most stdlibs on 1.10 and e.g. LinearAlgebra on 1.11). So removing extensions for the stdlibs might enough (and worth trying). cc @jw3126 |
Here is a somewhat untested patch that tries to avoid the diff --git a/base/Base.jl b/base/Base.jl
index 0ca13265ad..98803cf29f 100644
--- a/base/Base.jl
+++ b/base/Base.jl
@@ -627,6 +627,7 @@ function __init__()
init_load_path()
init_active_project()
append!(empty!(_sysimage_modules), keys(loaded_modules))
+ empty!(required_modules)
if haskey(ENV, "JULIA_MAX_NUM_PRECOMPILE_FILES")
MAX_NUM_PRECOMPILE_FILES[] = parse(Int, ENV["JULIA_MAX_NUM_PRECOMPILE_FILES"])
end
diff --git a/base/loading.jl b/base/loading.jl
index 97aa9977a7..a87df18902 100644
--- a/base/loading.jl
+++ b/base/loading.jl
@@ -1343,7 +1343,7 @@ function _insert_extension_triggers(parent::PkgId, extensions::Dict{String, Any}
# TODO: Better error message if this lookup fails?
uuid_trigger = UUID(weakdeps[trigger]::String)
trigger_id = PkgId(uuid_trigger, trigger)
- if !haskey(Base.loaded_modules, trigger_id) || haskey(package_locks, trigger_id)
+ if !(trigger_id in required_modules) || haskey(package_locks, trigger_id)
trigger1 = get!(Vector{ExtensionId}, EXT_DORMITORY, trigger_id)
push!(trigger1, gid)
else
@@ -1965,8 +1965,11 @@ function _require_prelocked(uuidkey::PkgId, env=nothing)
end
end
+const required_modules = Set{PkgId}()
function __require_prelocked(uuidkey::PkgId, env=nothing)
assert_havelock(require_lock)
+ first_require = !(uuidkey in required_modules)
+ push!(required_modules, uuidkey)
if !root_module_exists(uuidkey)
newm = _require(uuidkey, env)
if newm === nothing
@@ -1977,6 +1980,7 @@ function __require_prelocked(uuidkey::PkgId, env=nothing)
# After successfully loading, notify downstream consumers
run_package_callbacks(uuidkey)
else
+ first_require && run_package_callbacks(uuidkey)
warn_if_already_loaded_different(uuidkey)
newm = root_module(uuidkey)
end With this I can precompile Accessors.jl with no problems, but I literally haven't tried anything else than that. Edit: I don't think the above is completely correct. |
That's what we did in Accessors for now. |
They only have one extension for an stdlib. If they added another one, they might encounter the same problem. The issue AFAIU is that:
If you only have one extension there is no way to "loop back" to the first extension as in the example above. |
Maybe not? I see such errors with this package:
Many of the packages above are currently private, unfortunately. Let me know if more information is needed. Edit: I am not sure how to reproduce the error. Will edit next time I see the error. Edit: Stack trace:
|
…re in the sysimage (#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes #52132.
…re in the sysimage (#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes #52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
This issue is marked as closed, but still reproduces on 1.10.1, at least partially. @KristofferC Output _ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.10.1 (2024-02-13)
_/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |
(@v1.10) pkg> activate --temp
Activating new project at `/var/folders/2j/9vtd991d201dbkh9dnx3wvy00000gq/T/jl_Jy6kID`
(jl_Jy6kID) pkg> add AccessorsExtra
Resolving package versions...
Updating `/private/var/folders/2j/9vtd991d201dbkh9dnx3wvy00000gq/T/jl_Jy6kID/Project.toml`
[33016aad] + AccessorsExtra v0.1.68
Updating `/private/var/folders/2j/9vtd991d201dbkh9dnx3wvy00000gq/T/jl_Jy6kID/Manifest.toml`
[7d9f7c33] + Accessors v0.1.35
[33016aad] + AccessorsExtra v0.1.68
[a33af91c] + CompositionsBase v0.1.2
[187b0558] + ConstructionBase v1.5.4
[02685ad9] + DataPipes v0.3.14
[3587e190] + InverseFunctions v0.1.12
[1914dd2f] + MacroTools v0.5.13
[189a3867] + Reexport v1.2.2
[56f22d72] + Artifacts
[2a0f44e3] + Base64
[ade2ca70] + Dates
[b77e0a4c] + InteractiveUtils
[8f399da3] + Libdl
[37e2e46d] + LinearAlgebra
[56ddb016] + Logging
[d6f4376e] + Markdown
[de0858da] + Printf
[9a3f8284] + Random
[ea8e919c] + SHA v0.7.0
[9e88b42a] + Serialization
[8dfed614] + Test
[4ec0a83e] + Unicode
[e66e0078] + CompilerSupportLibraries_jll v1.1.0+0
[4536629a] + OpenBLAS_jll v0.3.23+4
[8e850b90] + libblastrampoline_jll v5.8.0+1
Precompiling project...
3 dependencies successfully precompiled in 4 seconds. 9 already precompiled.
1 dependency had output during precompilation:
┌ AccessorsExtra → LinearAlgebraExt
│ ┌ Warning: Module LinearAlgebraExt with build ID ffffffff-ffff-ffff-0003-d7c6509dfd87 is missing from the cache.
│ │ This may mean LinearAlgebraExt [2e571e4a-e68d-5fe4-9022-ff2e7d6ac6d5] does not support precompilation but is imported by a module that does.
│ └ @ Base loading.jl:1948
│ ┌ Error: Error during loading of extension LinearAlgebraExt of AccessorsExtra, use `Base.retry_load_extensions()` to retry.
│ │ exception =
│ │ 1-element ExceptionStack:
│ │ Declaring __precompile__(false) is not allowed in files that are being precompiled.
│ │ Stacktrace:
│ │ [1] _require(pkg::Base.PkgId, env::Nothing)
│ │ @ Base ./loading.jl:1952
│ │ [2] __require_prelocked(uuidkey::Base.PkgId, env::Nothing)
│ │ @ Base ./loading.jl:1812
│ │ [3] #invoke_in_world#3
│ │ @ ./essentials.jl:926 [inlined]
│ │ [4] invoke_in_world
│ │ @ ./essentials.jl:923 [inlined]
│ │ [5] _require_prelocked
│ │ @ ./loading.jl:1803 [inlined]
│ │ [6] _require_prelocked
│ │ @ ./loading.jl:1802 [inlined]
│ │ [7] run_extension_callbacks(extid::Base.ExtensionId)
│ │ @ Base ./loading.jl:1295
│ │ [8] run_extension_callbacks(pkgid::Base.PkgId)
│ │ @ Base ./loading.jl:1330
│ │ [9] run_package_callbacks(modkey::Base.PkgId)
│ │ @ Base ./loading.jl:1164
│ │ [10] __require_prelocked(uuidkey::Base.PkgId, env::String)
│ │ @ Base ./loading.jl:1819
│ │ [11] #invoke_in_world#3
│ │ @ ./essentials.jl:926 [inlined]
│ │ [12] invoke_in_world
│ │ @ ./essentials.jl:923 [inlined]
│ │ [13] _require_prelocked(uuidkey::Base.PkgId, env::String)
│ │ @ Base ./loading.jl:1803
│ │ [14] macro expansion
│ │ @ ./loading.jl:1790 [inlined]
│ │ [15] macro expansion
│ │ @ ./lock.jl:267 [inlined]
│ │ [16] __require(into::Module, mod::Symbol)
│ │ @ Base ./loading.jl:1753
│ │ [17] #invoke_in_world#3
│ │ @ ./essentials.jl:926 [inlined]
│ │ [18] invoke_in_world
│ │ @ ./essentials.jl:923 [inlined]
│ │ [19] require(into::Module, mod::Symbol)
│ │ @ Base ./loading.jl:1746
│ │ [20] include
│ │ @ ./Base.jl:495 [inlined]
│ │ [21] 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:2222
│ │ [22] top-level scope
│ │ @ stdin:3
│ │ [23] eval
│ │ @ ./boot.jl:385 [inlined]
│ │ [24] include_string(mapexpr::typeof(identity), mod::Module, code::String, filename::String)
│ │ @ Base ./loading.jl:2076
│ │ [25] include_string
│ │ @ ./loading.jl:2086 [inlined]
│ │ [26] exec_options(opts::Base.JLOptions)
│ │ @ Base ./client.jl:316
│ │ [27] _start()
│ │ @ Base ./client.jl:552
│ └ @ Base loading.jl:1301 |
AFAIK, #52841 was only intended to fix some of this issue / mitigate this bug in some cases, but not actually to close it? |
The relevant issue for other examples similar to this is #52511 |
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
…re in the sysimage (JuliaLang#52841) When triggers of extension are in the sysimage it is easy to end up with cycles in package loading. Say we have a package A with exts BExt and CExt and say that B and C is in the sysimage. - Upon loading A, we will immidiately start to precompile BExt (because the trigger B is "loaded" by virtue of being in the sysimage). - BExt will load A which will cause CExt to start precompiling (again because C is in the sysimage). - CExt will load A which will now cause BExt to start loading and we get a cycle. This is fixed in this PR by instead of looking at what modules are loaded, we look at what modules are actually `require`d and only use that to drive the loading of extensions. Fixes JuliaLang#52132. (cherry picked from commit 08d229f)
Reproducing in a clean env & depot, latest Julia (1.9.3; upd same on 1.9.4 and 1.10):
Still, it seems like code from these two extensions is actually loaded and works.
I don't have
__precompile__(false)
anywhere in that package, all modules should support precompilation. What these errors and warnings actually mean, and are they bugs in Julia or in package code?The text was updated successfully, but these errors were encountered: