Thanks. I gave it a try, and the result is disappointing: I took the example as it is and followed the instructions but it hang up at compiling a “nonincremental system image”. (I have no clue what that term actually means.)
Did you get an error or did it just hang? How long did you wait? It might not be the fastest thing… 
Nonetheless, what you’re seeing is that, for this kind of use case, Julia is currently a little rough around the edges, as we say. But that’s why there’s a fair amount of work going into the compiler.
I let it run and after 3.5 hours I stopped it. I saw that Julia consumes zero RAM and CPU, thus it kind of ended itself.
I only tried to get the official example library to compile. This must be possible.
3 Likes
Could you concisely document the exact steps you’re taking here and what’s going wrong? The example library is indeed part of the test-suite and should work on all platforms. You can see the tests themselves for a very concise minimal-working-example for the example:
2 Likes
Yes and I hope we will find the issue that way:
- I purposely made a fresh installation of Julia 1.11.4 (no other Julia version on that PC)
- I downloaded the source code of PackageCompiler 2.20 as ZIP and extracted the ZIP
- I put the folder “MyLib” folder from the ZIP file to this folder “D:\usti\Julia\MyLib”
- I start Julia’s REPL and add first the package PackageCompiler
- now I change to the source directory:
cd("D:\\usti\\Julia") - I execute
using PackageCompiler
create_library("MyLib", "MyLibCompiled";
lib_name="libinc",
precompile_execution_file="D:\\usti\\Julia\\MyLib\\build\\generate_precompile.jl",
precompile_statements_file="D:\\usti\\Julia\\MyLib\\build\\additional_precompile.jl",
header_files = ["D:\\usti\\Julia\\MyLib\\build\\mylib.h"])
The output in the console is this:
PackageCompiler: bundled libraries:
├── Base:
│ ├── libLLVM-16jl.dll - 81.906 MiB
│ ├── libatomic-1.dll - 247.061 KiB
│ ├── libdSFMT.dll - 99.613 KiB
│ ├── libgcc_s_seh-1.dll - 752.555 KiB
│ ├── libgfortran-5.dll - 11.147 MiB
│ ├── libgmp-10.dll - 1.039 MiB
│ ├── libgmp.dll - 1.039 MiB
│ ├── libgmpxx-4.dll - 278.288 KiB
│ ├── libgmpxx.dll - 278.288 KiB
│ ├── libgomp-1.dll - 1.631 MiB
│ ├── libjulia-codegen.dll - 103.432 MiB
│ ├── libjulia-internal.dll - 12.996 MiB
│ ├── libmpfr-6.dll - 2.512 MiB
│ ├── libmpfr.dll - 2.512 MiB
│ ├── libopenlibm.dll - 519.881 KiB
│ ├── libpcre2-16-0.dll - 697.275 KiB
│ ├── libpcre2-16.dll - 697.275 KiB
│ ├── libpcre2-32-0.dll - 668.666 KiB
│ ├── libpcre2-32.dll - 668.666 KiB
│ ├── libpcre2-8-0.dll - 759.307 KiB
│ ├── libpcre2-8.dll - 759.307 KiB
│ ├── libpcre2-posix-3.dll - 112.437 KiB
│ ├── libquadmath-0.dll - 1.122 MiB
│ ├── libssp-0.dll - 129.288 KiB
│ ├── libstdc++-6.dll - 25.172 MiB
│ ├── libuv-2.dll - 969.242 KiB
│ ├── libwinpthread-1.dll - 314.693 KiB
│ ├── libz.dll - 217.723 KiB
│ ├── libjulia.dll - 211.878 KiB
├── Stdlibs:
│ ├── OpenBLAS_jll
│ │ ├── libopenblas64_.dll - 37.654 MiB
│ ├── libblastrampoline_jll
│ │ ├── libblastrampoline-5.dll - 2.235 MiB
Total library file size: 292.581 MiB
✔ [03m:15s] PackageCompiler: creating compiler .ji image (incremental=false)
✔ [02m:43s] PackageCompiler: compiling fresh sysimage (incremental=false)
⠙ [02m:32s] PackageCompiler: compiling nonincremental system image
The “compiling nonincremental system image” lasts forever. I stopped it after 3.5 hours. The point is that even after 30 seconds, in the task manager of Windows i see that Julia is no longer doing anything:
(no RAM or CPU usage)
I got a new folder “MyLibCompiled” (D:\usti\Julia\MyLibCompiled) but it contaony no file called “libinc.dll” or MyLib.dll". All DLLs in that folder are those listed above in the console output.
4 Likes
Can you try it with exactly the options here:
That is, add incremental=false, force=true, filter_stdlibs=true?
Is there a reason you chose to install this way rather than using the regular package manager?
It might be worth running the code after installing the “official” way.
using Pkg
Pkg.add("PackageCompiler")
This is what I did in my step “I start Julia’s REPL and add first the package PackageCompiler”.
Julia is at a network drive and I wanted to have the PackageCompiler example files locally, thus in another directory than Julia.
Done now. But the outcome is exactly the same, so still no “libinc.dll”
I followed the PackageCompiler docs and there the options
incremental=false, force=true, filter_stdlibs=true
are not used. If they are necessary, please add them to the docs.
Regarding the docs, I miss a documentation of the options. There is no info what e.g. precompile_execution_file means, what “precompilation” means. Or what is the difference between incrementatal and nonincremental system images is, why there is first an incremental one created then subsequently a nonincremental…
As new user you are left with many questions.
I’m just trying to nail down what’s happening in the first place. I know those tests run and work on Windows CI. So if you can run exactly those tests and still have trouble it means there’s something else going on.
Is your D: drive that network drive? Does import Pkg; Pkg.test("PackageCompiler") work?
The Julia.exe is in
J:\Julia-1.11\bin
(J:\ is a network drive because at the local C:\ there is not enough space available for Julia.)
The package "PackageCompiler is in
J:\Julia-1.11\Packages\packages\PackageCompiler
(the Windows environment variable
JULIA_DEPOT_PATH
is set to
J:\Julia-1.11\Packages)
The MyLib example files are all in D:\usti\Julia\MyLib. (D:\ is a local harddrive)
Starting a new REPL, then
import Pkg; Pkg.test("PackageCompiler")
leads to:
_
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.11.4 (2025-03-10)
_/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |
julia> cd("D:\\usti\\Julia")
julia> import Pkg; Pkg.test("PackageCompiler")
Testing PackageCompiler
Status `C:\Users\Uwe\AppData\Local\Temp\jl_aWDcAT\Project.toml`
[7876af07] Example v0.5.5
[c27321d9] Glob v1.3.1
[9b87118b] PackageCompiler v2.2.0
[05181044] RelocatableFolders v1.0.1
[56f22d72] Artifacts v1.11.0
[4af54fe1] LazyArtifacts v1.11.0
[8f399da3] Libdl v1.11.0
[44cfe95a] Pkg v1.11.0
[de0858da] Printf v1.11.0
[fa267f1f] TOML v1.0.3
[8dfed614] Test v1.11.0
[cf7118a7] UUIDs v1.11.0
[3f19e933] p7zip_jll v17.4.0+2
Status `C:\Users\Uwe\AppData\Local\Temp\jl_aWDcAT\Manifest.toml`
[7876af07] Example v0.5.5
[c27321d9] Glob v1.3.1
[9b87118b] PackageCompiler v2.2.0
[05181044] RelocatableFolders v1.0.1
[6c6a2e73] Scratch v1.2.1
[0dad84c5] ArgTools v1.1.2
[56f22d72] Artifacts v1.11.0
[2a0f44e3] Base64 v1.11.0
[ade2ca70] Dates v1.11.0
[f43a241f] Downloads v1.6.0
[7b1f6079] FileWatching v1.11.0
[b77e0a4c] InteractiveUtils v1.11.0
[4af54fe1] LazyArtifacts v1.11.0
[76f85450] LibGit2 v1.11.0
[8f399da3] Libdl v1.11.0
[56ddb016] Logging v1.11.0
[d6f4376e] Markdown v1.11.0
[ca575930] NetworkOptions v1.2.0
[44cfe95a] Pkg v1.11.0
[de0858da] Printf v1.11.0
[ea8e919c] SHA v0.7.0
[9e88b42a] Serialization v1.11.0
[fa267f1f] TOML v1.0.3
[a4e569a6] Tar v1.10.0
[8dfed614] Test v1.11.0
[cf7118a7] UUIDs v1.11.0
[4ec0a83e] Unicode v1.11.0
[deac9b47] LibCURL_jll v8.6.0+0
[e37daf67] LibGit2_jll v1.7.2+0
[29816b5a] LibSSH2_jll v1.11.0+1
[c8ffd9c3] MbedTLS_jll v2.28.6+0
[14a3606d] MozillaCACerts_jll v2023.12.12
[83775a58] Zlib_jll v1.2.13+1
[8e850ede] nghttp2_jll v1.59.0+0
[3f19e933] p7zip_jll v17.4.0+2
Testing Running tests...
Installing known registries into `C:\Users\Uwe\AppData\Local\Temp\jl_qW5QW1`
Added `General` registry to C:\Users\Uwe\AppData\Local\Temp\jl_qW5QW1\registries
Updating registry at `C:\Users\Uwe\AppData\Local\Temp\jl_qW5QW1\registries\General.toml`
Resolving package versions...
Installed Example ─ v0.5.5
Updating `C:\Users\Uwe\AppData\Local\Temp\jl_L5e7Bq\Project.toml`
[7876af07] + Example v0.5.5
Updating `C:\Users\Uwe\AppData\Local\Temp\jl_L5e7Bq\Manifest.toml`
[7876af07] + Example v0.5.5
Precompiling project...
1 dependency successfully precompiled in 1 seconds
Downloaded artifact: mingw-w64
┌ Debug: instantiating project at "C:\\Users\\Uwe\\AppData\\Local\\Temp\\jl_L5e7Bq"
└ @ PackageCompiler J:\Julia-1.11\Packages\packages\PackageCompiler\UbaS4\src\PackageCompiler.jl:577
┌ Debug: ensurecompiled: running `'J:\Julia-1.11\bin\julia.exe' --color=yes --startup-file=no --pkgimages=no '--sysimage=J:\Julia-1.11\lib\julia\sys.dll' -e 'using Pkg; Pkg.precompile()'`
│ JULIA_LOAD_PATH = "C:\\Users\\Uwe\\AppData\\Local\\Temp\\jl_L5e7Bq;@stdlib"
└ @ PackageCompiler J:\Julia-1.11\Packages\packages\PackageCompiler\UbaS4\src\PackageCompiler.jl:298
Precompiling project...
1 dependency successfully precompiled in 1 seconds
┌ Debug: running precompilation execution script...
└ @ PackageCompiler J:\Julia-1.11\Packages\packages\PackageCompiler\UbaS4\src\PackageCompiler.jl:350
┌ Debug: run_precompilation_script: running `'J:\Julia-1.11\bin\julia.exe' --color=yes --startup-file=no --pkgimages=no '--sysimage=J:\Julia-1.11\lib\julia\sys.dll' --compile=all '--trace-compile=C:\Users\Uwe\AppData\Local\Temp\jl_packagecompiler_Mk7Zg3\jl_F3D0.tmp' 'J:\Julia-1.11\Packages\packages\PackageCompiler\UbaS4\test\precompile_execution.jl'`
│ JULIA_LOAD_PATH = "C:\\Users\\Uwe\\AppData\\Local\\Temp\\jl_L5e7Bq;@stdlib"
└ @ PackageCompiler J:\Julia-1.11\Packages\packages\PackageCompiler\UbaS4\src\PackageCompiler.jl:311
[ Info: PackageCompiler: Executing J:\Julia-1.11\Packages\packages\PackageCompiler\UbaS4\test\precompile_execution.jl => C:\Users\Uwe\AppData\Local\Temp\jl_packagecompiler_Mk7Zg3\jl_F3D0.tmp
[ Info: PackageCompiler: Done
┌ Debug: writing precompile staging code to C:\Users\Uwe\AppData\Local\Temp\jl_rax0BmN2Ra
└ @ PackageCompiler J:\Julia-1.11\Packages\packages\PackageCompiler\UbaS4\src\PackageCompiler.jl:461
┌ Debug: running `'J:\Julia-1.11\bin\julia.exe' --color=yes --startup-file=no --pkgimages=no --cpu-target=native -O1 '--sysimage=J:\Julia-1.11\lib\julia\sys.dll' '--project=C:\Users\Uwe\AppData\Local\Temp\jl_L5e7Bq' '--output-o=C:\Users\Uwe\AppData\Local\Temp\jl_Nc96DwlSl2-o.a' 'C:\Users\Uwe\AppData\Local\Temp\jl_rax0BmN2Ra'`
└ @ PackageCompiler J:\Julia-1.11\Packages\packages\PackageCompiler\UbaS4\src\PackageCompiler.jl:468
⠸ [04m:20s] PackageCompiler: compiling incremental system image
“compiling incremental system image runs forever”, there is no CPU consumption of the Julia.exe.
also the file C:\Users\Uwe\AppData\Local\Temp\jl_Nc96DwlSl2-o.a is not created.
It may be worth trying to see if the same behaviour persists with non-network drives. I have occasionally encountered issues with Windows network drives while using Julia through Parallels Desktop on MacOS, which I can no longer recall; however, these experiences led me to consistently ensure that the application runs on the main drive as a precautionary measure.
2 Likes
I spent now hours but the result is still the same. I tried this:
- installed Julia 1.11.4 on a PC that has never seen Julia before on a local harddrive. By default Julia was installed for the current user
- Since this did not help, I uninstalled Julia then reinstalled Julia ad Admin for all users.
This lead to a complete buggy Julia installation since Julia is actually not installed for all users but only for the current admin user. → The Julia Windows installer has a lot of bugs but sending bug reports even with giving the solution, nobody cares
- So I tried it being the admin user
But the outcome is always exactly as I reported:
I will now file a bug report and also bug reports for the Windows installer of Julia.
However, I think Julia does not like Windows. But since years now I have not seen any desktop PC in any lab or office that runs not Windows or MacOS, therefore I don’t understand this decision. In another thread I even found out that compilers are hardcoded as they are in Unix.
It does not matter what I like, all my customers and also colleagues use Windows. Either I can use Julia on Windows without becoming an IT specialist or I must leave it and that would be sad.
1 Like
After many hours of trying I found the solution and the bug in PackageCompiler.
At first the step by step instruction:
- Assure that the python.exe is in the PATH environment variable (either the one of the current user or the system-wide one)
- Assure that you don’t have a Julia thread setting as environment variable, so there must not be an environment variable called
JULIA_NUM_THREADS - Start Julia and change to the source directory, for example:
cd("D:\\Julia") - Execute
using PackageCompiler - Execute this command:
create_library("MyLib", "MyLibCompiled";
lib_name="libinc",
precompile_execution_file="D:\\Julia\\MyLib\\build\\generate_precompile.jl",
precompile_statements_file="D:\\\Julia\\MyLib\\build\\additional_precompile.jl",
header_files = ["D:\\Julia\\MyLib\\build\\mylib.h"])
whereas “MyLib” is the name of the subfolder of “D:\Julia” (so “D:\Julia\MyLib”), “LyLibCompiled” will become a new folder with the compilation results. “libinc” will be the name of the created library (“libinc.dll”). For the statements of precompile_execution_file etc. take the skeleton of the files and file structure given in the examples folder of the PackageCompiler docs.
The bug making PackageCompiler failing
Since my application are neuronal networks and the computation time reduces a lot when using multiple of the CPU threads, I use the environment variable JULIA_NUM_THREADS
But if this is set, no matter to what value, PackageCompiler runs forever, not creating any library or app and you also get no information why it fails.
8 Likes
It’s these issues
- Where did you report it, I don’t see an newer open issue or new comments on the existing ones. Comment on the existing ones, opening a new one will likely be closed as a duplicate and linked to the existing ones unless there’s a novel aspect.
- It’s a third-party library, not a part of Julia, and I’ve never heard it called production-ready. If it were, I’d expect
[compat]patches to stop people from running into problematic dependency updates like this.
5 Likes
If you have issues, please file an issue on github in those repositories. It will bring awareness to the developers of your pain points.
I’m sure your expectations are how things work somewhere else and they work well, but it has consistently lead to incorrect assumptions. I know you’ve mentioned that you’re not familiar with Github, so:
- You didn’t link a repository, that’s a Github organization. If you click your link then the “Repositories” tab, you can see the list of repositories associated with it.
- Different repositories are typically developed independently, though you would expect more communication within organizations. PackageCompiler is independently developed from Julia, and it’s not part of the standard library like Pkg. The small element of truth is that there has been talks in recent years of base Julia doing something like PackageCompiler, which sounds a lot like the upcoming juliac.
- Repositories don’t automatically promise production-readiness if a separate repository in the same organization is. The simplest counterexamples are obsolete repositories that are archived to stop people from trying to use them.
This isn’t a fringe development culture, Github has been around for 17 years.
3 Likes
There is a known regression for half a year but since it it not part of the standard library, there is no need to act. New releases are made, users are not informed about the regression, the release notes don’t mention any regression nor a workaround. For you the case is then closed.
What QA policy do you follow? As user I cannot know how the project is lead, all I see is that a core feature (a feature that Julia is actively promoting) is not working.
Nobody made this claim.
I don’t, I’m a user as well. If you want to communicate with PackageCompiler contributors on this particular issue, I linked the likely Github issues. Making demands of other users on a discourse forum isn’t going to accomplish anything, let alone making demands of developers. If you’d like to contribute to a feature you want, you’re free to.
Repeating a debunked claim won’t make it true.
1 Like