Is it possilbe to call a .dll compiled via julia itself?

General Usage
1

For instance, some code files need to be communicated with cooperators, but with critical information concealed. All the files could be compiled as .dll (in windows), so the question is whether it is possible to call a .dll compiled via the julia itself.

2

https://www.reddit.com/r/Julia/comments/17tot82/state_of_compile_to_binary_in_late_2023/

GitHub - tshort/StaticCompiler.jl: Compiles Julia code to a standalone library (experimental) can do this, but only for a very limited subset of Julia.

PackageCompiler.jl might be an alternative, but the result is very large.

1 Like
3

At the moment, you still have to initialize the Julia runtime. But then you can call functions marked by @ccallable.

See GitHub - simonbyrne/libcg for an example.

Soon this will be outdated.

6 Likes
4

I know how to compile dll via PackageCompiler.jl, but let me reiterate my question that whether .dll files compiled by PackageCompiler.jl could be called by the Julia language via ccall?

5

What I know is that you cannot embed two FMUs that contain Julia dlls created with package compiler into one Simulink model because you would then have to include the Julia runtime twice which does not work.

I never tried to embed a Julia dll into a Julia program, so I do not know if it works, but why not? Just try it out.

1 Like
6

Let me repeat the answer.

Follow the template used by libcg:

A ccallable function can be called as a regular C function in the system image. See the libcg code.

Expect the answer to be different in a week.

1 Like
7

ā€œsoonā€ as in ā€œa PR was posted already two days agoā€: add --static-call-graph option for generating smaller binaries by JeffBezanson Ā· Pull Request #55047 Ā· JuliaLang/julia Ā· GitHub (this is only for executables though, not yet for shared libraries, although I think most of the work to get there is already laid out).

2 Likes
8

While Iā€™m also very curious about where this will eventually go, letā€™s not overhype ourselves. The ā€œHello Worldā€ example from that PR comes in at a whopping 900KB (stripped from debug symbols etc - without that, itā€™s 1.6MB), which includes a whole bunch of stuff that isnā€™t needed at runtime at all. For example, thereā€™s error strings for string calls on <:Integer ("For negative `x`, `base` must be negative."), some stuff for PCRE (even though there are no regexes used in the ā€œHello Worldā€ example) and lots of things that only make sense when reflection is used. All that is visible through a simple strings hello | less.

In comparison, a similar example with StaticCompiler.jl comes in at 9KB(!) - thatā€™s 100x overhead, presumably for some runtime initialization (since things like array allocations seem to work, which donā€™t with StaticCompiler?). I suspect that this is due to the different approaches taken to arrive at the binary - the binary produced by that PR seems to just dump its internal state in a sysimage, placed in a opaque section in the ELF, loaded & reinitialized at runtime. Thatā€™s not very optimizable with standard tooling, which assumes adherence to ELF sections :person_shrugging:

For the curious, when comparing other languages to this PR, weā€™d end up somewhere between D and C# size-wise, with StaticCompiler.jl ending up somewhere between Zig and Nim (with C, C++ & Rust squarely inbetween those ranges themselves). This is of course amazingly better than the 300MB+ we had so far, but also shows that thereā€™s still a lot of room for improvement left :slight_smile:

On the upside, the ā€œstartup timeā€ for this is :fire:

[sukera@tower juliac]$ time ./hello
Hello, world!

real	0m0.032s
user	0m0.005s
sys	    0m0.032s

(though of course, thereā€™s also room for improvement there; we donā€™t really need to initialize all threads for example, which does happen - strace ./hello does not look very kind here :joy:)

I guess weā€™ll have to wait & see what will be presented in the talk & what the future plans for this are. Incremental improvements have been the name of the game so far after all, and paid off very well for loading times & general performance. Still though - letā€™s not overhype ourselves just yet, and be a bit patient :heart:

1 Like
9

A PR to showcase building a shared library with juliac just landed:

1 Like