# Is it possilbe to call a .dll compiled via julia itself?
**URL:** https://discourse.julialang.org/t/is-it-possilbe-to-call-a-dll-compiled-via-julia-itself/116710
**Category:** General Usage
**Tags:** compilation
**Created:** [July 7, 2024, 4:34am UTC](https://discourse.julialang.org/t/is-it-possilbe-to-call-a-dll-compiled-via-julia-itself/116710 "2024-07-07T04:34:03Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@lionisxn](https://discourse.julialang.org/u/lionisxn)
#### Post date: [July 7, 2024, 4:34am UTC](https://discourse.julialang.org/t/is-it-possilbe-to-call-a-dll-compiled-via-julia-itself/116710/1 "2024-07-07T04:34:03Z")
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.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [July 7, 2024, 8:44am UTC](https://discourse.julialang.org/t/is-it-possilbe-to-call-a-dll-compiled-via-julia-itself/116710/2 "2024-07-07T08:44:55Z")
[https://www.reddit.com/r/Julia/comments/17tot82/state\_of\_compile\_to\_binary\_in\_late\_2023/](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)](https://github.com/tshort/StaticCompiler.jl) can do this, but only for a very limited subset of Julia.
PackageCompiler.jl might be an alternative, but the result is very large.
---
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [July 7, 2024, 8:55am UTC](https://discourse.julialang.org/t/is-it-possilbe-to-call-a-dll-compiled-via-julia-itself/116710/3 "2024-07-07T08:55:54Z")
At the moment, you still have to initialize the Julia runtime. But then you can call functions marked by `@ccallable`.
See [GitHub - simonbyrne/libcg](https://github.com/simonbyrne/libcg) for an example.
Soon this will be outdated.
> **[New Ways to Compile Julia Juliacon 2024](https://pretalx.com/juliacon2024/talk/FUTLND/)**
>
> We will explain new options for ahead-of-time compilation of julia programs that we have been developing. First, there is a new compiler driver \`juliac\` that provides a more traditional gcc-like command-line interface. Next, we are adding new...
---
### Author:  [@lionisxn](https://discourse.julialang.org/u/lionisxn)
#### Post date: [July 7, 2024, 9:34am UTC](https://discourse.julialang.org/t/is-it-possilbe-to-call-a-dll-compiled-via-julia-itself/116710/4 "2024-07-07T09:34:03Z")
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?
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [July 7, 2024, 4:36pm UTC](https://discourse.julialang.org/t/is-it-possilbe-to-call-a-dll-compiled-via-julia-itself/116710/5 "2024-07-07T16:36:32Z")
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.
---
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [July 7, 2024, 4:53pm UTC](https://discourse.julialang.org/t/is-it-possilbe-to-call-a-dll-compiled-via-julia-itself/116710/6 "2024-07-07T16:53:46Z")
Let me repeat the answer.
Follow the template used by libcg:
> **[GitHub - simonbyrne/libcg](https://github.com/simonbyrne/libcg)**
>
> Contribute to simonbyrne/libcg development by creating an account on GitHub.
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.
---
### Author:  [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [July 8, 2024, 12:19am UTC](https://discourse.julialang.org/t/is-it-possilbe-to-call-a-dll-compiled-via-julia-itself/116710/7 "2024-07-08T00:19:08Z")
> [@mkitti](#):
>
> Soon this will be outdated.
>
> [New Ways to Compile Julia :: Juliacon 2024 :: pretalx](https://pretalx.com/juliacon2024/talk/FUTLND/)
“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](https://github.com/JuliaLang/julia/pull/55047) (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).
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [July 8, 2024, 5:56am UTC](https://discourse.julialang.org/t/is-it-possilbe-to-call-a-dll-compiled-via-julia-itself/116710/8 "2024-07-08T05:56:30Z")
> [@mkitti](#):
>
> Soon this will be outdated.
> [@giordano](#):
>
> “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](https://github.com/JuliaLang/julia/pull/55047) (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).
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 🤷
For the curious, when comparing [other languages](https://github.com/MichalStrehovsky/sizegame) 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 🙂
On the upside, the “startup time” for this is 🔥
```julia
[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 😂)
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 ❤
---
### Author:  [@giordano](https://discourse.julialang.org/u/giordano)
#### Post date: [July 11, 2024, 8:32pm UTC](https://discourse.julialang.org/t/is-it-possilbe-to-call-a-dll-compiled-via-julia-itself/116710/9 "2024-07-11T20:32:14Z")
> [@giordano](#):
>
> (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)
A PR to showcase building a shared library with `juliac` just landed:
>
>
> Note this is a PR against #55047
>
> Co-authored by: Gabriel Baraldi \