Creating fully self-contained and pre-compiled library

General Usage
21

For my use case it seems libjulia-codegen and libLLVM are not required anymore at runtime, which is also the “promise” of trimming. Do you know which library requires it? I am pretty sure I am using some of the artifacts (it doesn’t run without), but haven’t looked too much into which ones.

22

I get the ccall requires compiler error, package is HiGHS.jl, see Creating fully self-contained and pre-compiled library - #15 by asprionj. I don’t get any more details as error message, since it happens at runtime… so I don’t know exactly which library it is since there are multiple artifacts required (by the chain of dependencies of HiGHS.jl).

My question basically is if any ccall requires the two libs (LLVM and codegen), or if this only applies if the artifacts are left in their default folder that “normal julia” relies on…

23

I see. But JET.@testopt reports no errors? What about juliac --trim?

24

I don’t know what this is supposed to mean and I also wouldn’t expect ccall to require compiling Julia. The message shows up here (and possibly elsewhere, I haven’t checked), and this error is described in the PythonCall FAQ as a libstdc++ incompatibility with the Python side. Not apparent if that’s related to HiGHS. I think it was implied, but do you not run into this error when running the same or equivalent code in typical REPL usage?

25

Thanks for the hints, will check them all later and update here. Especially I haven’t worked with JET so far, should give that one a try.

26

Ok, so one difference in our setups currently is that I just leave the artifacts where they are (and thus where they are expected by “normal julia”). On Windows, that’s something like C:\Users\<username>\.julia\artifacts. In contrast, you

just copy over the share directory that PackageCompiler comes up with

But where exactly do you put this share directory? I could try to manually do the same, just to see if that resolves the problem. Maybe the “runtime part of julia” is required if it needs to find artifacts “dynamically” at runtime…? I’d then probably also have to use the --relative-rpath option, I guess? Or does this just apply to the julia libraries, not the artifacts?

27

If you want to get rid of libcodegen and libllvm you need juliac --trim, and to get this to work it helps to appease JET. In my tests using etc totally works even with many packages. I also have a much more simplified repo that does just a simple trimming on NonlinearSolve.jl GitHub - RomeoV/TrimSimpleNonlinearSolve.jl.

28

Have to get into JET etc. a bit. For now I just use the jq-1.0 branch (a complete better rewrite) of JSON.jl. Having a JSON interface is the first step I need to take.

There’s a long output of @report_opt, it’s quite deeply nested, and all actual “runtime dispatch” errors are 1-5 levels below this:

││││││││││┌ print(io::IOBuffer, x::Type) @ Base ./strings/io.jl:35
│││││││││││┌ show(io::IOBuffer, x::Type) @ Base ./show.jl:968

Now it’s a bit hard for me to understand. First, I don’t print/show anything in my function I want to compile. Second, if the problem is in Base, it’s probably a long way (up to impossible) for me to “fix”, right?

EDIT: FYI, I gave juliac --trim a try anyway, and both on nightly and rc I get something around 100 trim-verify errors.

29

To understand the state of --trim better I recommend watching Jeff’s JuliaCon 2025 State of --trim talk here. In general, trimming will for the most part not “just work” for any Julia packages, as it only supports a subset of Julia functionality, and in particular no runtime dispatch and limited dynamic dispatch.

Therefore, most established libraries that have not been adapted with trimming in mind won’t work well with --trim, and may never work. In particular, file IO is inherently type unstable if you don’t know what you’ll be dealing with ahead of time yet. Similarly e.g. CLI parsing.
The JuliaHub team has made an HDF5 implementation that is trimmable: GitHub - gbaraldi/StaticHDF5.jl: Read and write julia arrays to HDF5 (the author of this package is also one of “the” juliac guys). Perhaps you can first convert your json file to hdf5 and then use that library. I have made a trimmable CLI parser GitHub - RomeoV/TrimmableCLIParser.jl if you are also looking for something like that.

Regarding having 100+ JET errors, that’s quite normal, but sometimes it only takes one fix to collapse all the errors. However, sometimes it also needs a complete redesign of how something works to be fully type inferrable. It really depends on the library.

2 Likes
30

My personal recommendation if you want to go forward: Make a number of self-contained minimum working/failing examples, similar to my GitHub - RomeoV/TrimSimpleNonlinearSolve.jl repo. Perhaps one for your HiGHS interface with hardcoded data, one for your File IO, etc. Make sure you find something that is fully JET compliant and try to --trim it, so that for everything on top of that you can bisect the changes to find out what made the code non-trimmable. Then, start opening concrete discussions about very concrete problems either here, on Slack static-compilation channel, on Zulip, or in an issue of the repo.
Some library maintainers are interested in pushing this forward (e.g. some of the SciML and the JuliaHub people). I haven’t talked to the JuMP people, perhaps @odow can comment on this himself. If the library maintainers are interested in pushing their library towards trimmability, it can be helpful to contribute tests to the upstream repos that test common functionality for @test_opt and work with them to fix issues. This seems daunting at first but becomes easier as you become more familiar with JET etc. For your own use, sometimes you can also just fork their repo and delete/hardcode some choices that are tripping up JET but where you don’t need the flexibility. However, of course it would be better to keep everything upstreamed.

Finally, it is not always necessary to actually remove all JET or trimming verifier errors. Essentially, if you have errors on code paths that you will actually never hit you are “fine”.

2 Likes
31

I haven’t talked to the JuMP people, perhaps @odow can comment on this himself. If the library maintainers are interested in pushing their library towards trimmability,

I have no personal plans to work on anything juliac related while it is experimental and requires an unreleased version of Julia. Ill take a look in 6 months or so.

But I’m happy to review/merge PRs if people want to do the work to find what changes are needed.

3 Likes