# Statically compiled and statically linked

**URL:** <https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290>\
**Category:** General Usage\
**Created:** [July 10, 2018, 12:23pm UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290 "2018-07-10T12:23:12Z")\
**Posts on this page:** 16\
**Page:** 2

<div class="post-metadata">

**Author:** ![RoyiAvital](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/royiavital/32/571_2.png) [@RoyiAvital](https://discourse.julialang.org/u/RoyiAvital)\
**Post date:** [August 9, 2018, 3:44pm UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/21 "2018-08-09T15:44:25Z")

</div>

You should edit your post and add a link to the video.

---

<div class="post-metadata">

**Author:** ![Jan\_Dolinsky](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jan_dolinsky/32/31347_2.png) [@Jan\_Dolinsky](https://discourse.julialang.org/u/Jan_Dolinsky)\
**Post date:** [August 9, 2018, 4:04pm UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/22 "2018-08-09T16:04:38Z")

</div>

Thanks. I just did.

Regards,  
Jan

---

<div class="post-metadata">

**Author:** ![rubyFeedback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rubyfeedback/32/16505_2.png) [@rubyFeedback](https://discourse.julialang.org/u/rubyFeedback)\
**Post date:** [July 20, 2020, 10:55pm UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/23 "2020-07-20T22:55:19Z")

</div>

> With respect, if static compilation/linking is the key feature  
> for someone, why would they want to use an essentially  
> dynamic language?

I will assume the question by Tamas\_Papp to be a genuine one  
rather than an arrogant top-down question belittling the use  
case of people.

I will explain my own use case - this may be different to the  
threadstarter, but remember the question here was posed  
in a general manner aka “why would xyz want to use a dynamic  
language”.

I am a heavy ruby guy. I wrote a “package” manager that is  
actually a crappy build system; horrible quality. Don’t  
anyone use it!

Anyway. I am tracking almost 4000 different packages so  
far - glibc, gcc, binutils etc… - you name it. All of  
KDE5, all of GNOME3, mate-desktop. Literally most of  
the currently used software stack. And I keep on adding  
to this.

I try to be independent, as much as possible, from  
distributions - we could see the nightmare of IBM Red  
Hat force-abusing everyone via systemd (and arrogant  
maintainers such as on debian refusing to give people  
a choice here, leading to the devuan-fork; anyway,  
this is a separate topic. I wanted to give a background.)

The key here is that I am independent.

Now - I am stuck, though, because I need a clean environment  
aka chroot. I can setup most of the chroot, but I do not  
understand everything really. In particular there are  
hardcoded paths but also glibc being annoying to no ends.  
And … ruby is not working in the chroot. Which is  
annoying. But a statically compiled bash is working as-is.  
So I could use bash scripts. But I hate them.

Compiling a static ruby is difficult. It is easy with  
mruby but … you need to know C. I don’t know C. I don’t  
want to invest xxx hours into mastering C.

I just want my scripts to work.

As it is, ruby does not work, python does not work, and  
getting lua to compile statically is ANNOYING to. So  
I was looking whether julia fits the bill.

It would be simpler for me to re-create the CORE aspects  
of my scripts (all the packages are actually stored in  
yaml files, so I have the information as-is; I can  
easily use another language too, which is different  
if you look at e. g. homebrew) in another language.

So right now I don’t know whether I can use a minimal  
julia, something simple, like --mini or --minijulia  
and --enable-static or something like that. That would  
be sweet.

No clue if that is possible, but my aim here was to  
answer the above question.

So my use case is not related to distributing a static  
binary to anyone - I just want my set of tools to work  
as it is. (I already tried to make it simpler for ruby  
to be compiled statically, and for python too but it  
just does not work for me … bash works fine, grep  
too, sed, awk … lots of packages work fine statically.  
I only need it for the initial bootstrap-part by the  
way. Once that works fine, I can bootstrap all the other  
parts on a linux system fine.)

> Especially if someone doesn’t already have julia installed,  
> installation times with download, precompilation, etc  
> easily range between 10-60 minutes right now.

> There is no question that this needs to be addressed,  
> especially if we want to reach a wider audience 😉

Different people have different use cases. IMO, ideally,  
in particular the “scripting” languages should be as  
flexible and dynamic as possible, to allow for people  
to use them in many different scenarios. Sure, C and  
C++ will always be faster, but I rather write scripts  
in simpler languages, and maintain them, then go and  
learn C and C++ properly because they are just less  
fun compared to, say, ruby. Or python too. (I can not  
use perl because I hate the syntax.)

By the way, for my use cases Go is not an option. I am  
aware of many people jumping to the Google empire  
but it is unlikely that I will - although this has less to do  
with Google per se, and more that I don’t feel Go is  
a “scripting” family really, whereas Julia fits a lot more  
there, IMO.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [July 20, 2020, 11:06pm UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/24 "2020-07-20T23:06:44Z")

</div>

There will be a talk about scripting in Julia at JuliaCon2020 (@fredrikekre might tell you more).

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [July 21, 2020, 1:58am UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/25 "2020-07-21T01:58:34Z")

</div>

I am actually kind of confused to what you’re trying to do. The original post is about statically compile Julia code and distribute an application written in Julia. Which is not what you’re trying to achieve.

If my understanding is correct, you’re trying to use Julia as a package manager, not as a package that is managed. (idk, something like `apt-get` except you build them from source?)

My confusion is essentially that, if your tool of choice lives on the host environment, why would Julia (or anything) needs to be statically compiled? If you just need some julia code to ‘just run’, use the official binary and run your core code once maybe? not sure if you have looked at [Yggdrasil](https://github.com/JuliaPackaging/Yggdrasil), which is a collection of scripts for building, well, softwares. Is this close to what your ruby manager does?

tl;dr - I understand if you need to build julia using some package manager, static linking can be a problem, but if you’re just using the software (given julia, python, or whatever) to write a package manager, I’m not sure what’s the difficulty truly is.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 21, 2020, 6:00am UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/26 "2020-07-21T06:00:55Z")

</div>

> [@rubyFeedback](#):
>
> the question by Tamas\_Papp to be a genuine one  
> rather than an arrogant top-down question belittling the use  
> case of people

I have read through your post twice and still don’t understand your use case.

Also, please don’t revive topics 2 years later — a lot has changed in the meantime. If you have a question, just open a new topic.

---

<div class="post-metadata">

**Author:** ![Mayank\_Gupta](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mayank_gupta/32/8327_2.png) [@Mayank\_Gupta](https://discourse.julialang.org/u/Mayank_Gupta)\
**Post date:** [August 30, 2020, 6:46am UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/27 "2020-08-30T06:46:15Z")

</div>

Hey Tamas,  
I wanted to answer your original question of why people might want to do static compilation of Julia programs. Julia is attempting to solve the two language problem. That is the same language for fast development and releasing fast performing code. Code that doesn’t need to be rewritten for a production environment.

In a production environment you typically want to release a statically linked binary. It’s simply a lot safer. That’s one huge use case for having support for statically linked binaries.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [August 30, 2020, 1:29pm UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/28 "2020-08-30T13:29:04Z")

</div>

Welcome to the Jula community. I think you’ll find what you need or want, with Julia as is or with non-default options (for e.g. binaries/hiding source code, while the binaries are currently non-small).

> [@Mayank\_Gupta](#):
>
> In a production environment you typically want to release a statically linked binary. It’s simply a lot safer.

It’s just not true, that it’s safer (in general). You may want to provide binaries anyway, and it’s possible. PackageCompiler.jl helps, using it gets you a systemimage/binary, in some sense similar to Java, not fully compiled to assembly (while looks and feels that way), and like Java, I believe it’s as safe, safer than binary (statically-linked or not) machine code.

# Static Linking Considered Harmful

> **[Static Linking Considered Harmful](http://web.archive.org/web/20080612143346/http://people.redhat.com/drepper/no_static_linking.html)**

> <https://security.stackexchange.com/questions/59101/should-statically-linked-server-binaries-daemons-be-deemed-more-secure/59114#59114>

> From a security standpoint, static linkage has one advantage and one weakness:  
> [..]  
> Library injection requires local access, while known-address attacks tend to be remote, so on the whole, I’d say that static linkage of server binaries is a net negative to security, in addition to its other drawbacks.

---

<div class="post-metadata">

**Author:** ![Mayank\_Gupta](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mayank_gupta/32/8327_2.png) [@Mayank\_Gupta](https://discourse.julialang.org/u/Mayank_Gupta)\
**Post date:** [August 31, 2020, 7:20pm UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/29 "2020-08-31T19:20:57Z")

</div>

Aha we are talking about two different uses of the word safer. You are talking about safer from a security point of view. I’m talking about safety from a static environment point of view. In the view I’m taking, the completely static environment of a docker container would be a logical conclusion.

Deploying statically linked binaries in a standardized server/computing environment is an important and regular use case. It reduces dependencies and is comparatively much safer than a dynamically linked system.

I agree package\_compiler.jl is part of the solution for this use case. I wanted to explain to Tamas, why people might care for package\_compiler.jl in the first place.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [August 31, 2020, 7:27pm UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/30 "2020-08-31T19:27:50Z")

</div>

You can use Docker with Julia, there are official Julia docker images out there (I’ve not used Docker, it shouldn’t require PackageCompiler to additionally use your Jown Julia code with?). But your claim vs. Julia’s Package/Artifact system may not be true. It’s at least supposed to nail everything down including all pure Julia code dependencies, or foreign language binaries (library or otherwise) used with (or I suppose Julia’s if wanted). There’s a loophole (related to old binary code from before the Artifact system, recent binaries should avoid that trap), not a big concern I think, but at least with Julia-only code it should be foolproof.

I think you mean easier for installation, less brittle, and that applies to many other languages, just to less or no extent to Julia. The Julia dependency system has been described as “a mini Linux distro” if I recall by Karpinski, and I e.g. noticed you can use it to install Perl (and Ruby), a specific version ([Readme · Perl\_jll.jl](https://juliahub.com/docs/Perl_jll/fYLMz/5.30.3+0/)), that happens to be more up-to-date than the one in my Ubuntu 18.04. Not yet, say PostgreSQL (meaning the full database, the driver LibPQ.jl is there), and I see value in your logic for such dependencies (and config files for such), while you often wouldn’t have a database on the same machine.

There’s nothing inherently forbidding the system installing a full database (that one or at least SQLite, seemingly already done with [JuliaHub](https://juliahub.com/ui/Packages?q=SQLite_jll) as appropriate for an embedded database) for you. I’ve done for JuliaDB.jl, a relational database written in pure Julia (it’s just not an SQL one, is not meant to replace multi-user DB). Relational-AI also does something similar.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [September 1, 2020, 8:43am UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/31 "2020-09-01T08:43:48Z")

</div>

Deploying Julia applications in a self-contained manner and reducing compilation/startup time are both reasonable requests, and some form precompilation is _part_ of the solution, but what people understand as static compilation/linking in C-like languages may be a red herring in the context of Julia.

Again, a lot has happened since the above discussion. **Instead of reviving it, please start a new one,** focusing on goals (“I want to deploy my Julia application, and this is whatI need help with”) instead of means (“I want static linking, whatever it means for Julia”). Cf [XY problem](https://en.wikipedia.org/wiki/XY_problem).

---

<div class="post-metadata">

**Author:** ![Mayank\_Gupta](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mayank_gupta/32/8327_2.png) [@Mayank\_Gupta](https://discourse.julialang.org/u/Mayank_Gupta)\
**Post date:** [September 1, 2020, 4:37pm UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/32 "2020-09-01T16:37:55Z")

</div>

Hey,  
I wasn’t saying Julia doesn’t support static compilation. I was commenting why even in a dynamic language like Julia such a feature would be useful. I was justifying package\_compiler.jl’s existence.

Having said that, you provided some interesting context and items to read, thank you.  
I’m checking them out!

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [September 1, 2020, 5:18pm UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/33 "2020-09-01T17:18:26Z")

</div>

> [@Mayank\_Gupta](#):
>
> I wasn’t saying Julia doesn’t support static compilation.

Yes, and no. If all your types are known you can compile to (even small, in theory) binaries, but in general you can’t! I mean, in general, the binary needs to include the compiler (and/or interpreter).

Think of the function:

```julia
mul(a, b) = a * b

```

Do you want to compile only for the integers, or floating point, or string concatenation or the infinite possible types, as Julia is generic? In general you could `@eval` at runtime, and solving this runs into the halting problem, theoretically not possible. Restricted Julia without being limited to being generic is still as powerful as e.g. C (you could e.g. type all your functions).

> [@What's actually inside precompiled Julia files?](https://discourse.julialang.org/t/whats-actually-inside-precompiled-julia-files/28234/2):
>
> Actually, many types are known when the module is loaded — any functions that are called during module initialization, along with any function for which [precompile](https://docs.julialang.org/en/latest/base/base/#Base.precompile) is called. The [SnoopCompile package](https://github.com/timholy/SnoopCompile.jl) can automatically generate precompile statements for functions that are called during a program execution. My understanding is that it’s currently the lowered+type-inferred code, plus the values of global variables (e.g. const foo = ...some expensive function...). When a precompiled module is …

---

<div class="post-metadata">

**Author:** ![RoyiAvital](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/royiavital/32/571_2.png) [@RoyiAvital](https://discourse.julialang.org/u/RoyiAvital)\
**Post date:** [September 1, 2020, 5:48pm UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/34 "2020-09-01T17:48:59Z")

</div>

You can solve it by defining the elements at the entry point to the function in the library.  
For instance, I create a Julia function as entry point and define its entry point are 2 double arrays and 2 scalars parameters.

From there I’d like the _Julia Coder_ to infer all the elements down the road.  
If there is an ambiguity somewhere, and it can infer the options which are limited, then do its magic. If not, return an error and ask the user to define those specific cases.

It might require some decorations or specific style of coding. But I think it is doable (Or at least this is not the main issue, no real need to support all cases or add the compiler).

---

<div class="post-metadata">

**Author:** ![Roger-luo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/roger-luo/32/3399_2.png) [@Roger-luo](https://discourse.julialang.org/u/Roger-luo)\
**Post date:** [September 8, 2020, 7:23am UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/35 "2020-09-08T07:23:19Z")

</div>

Regarding generating small self-contained binaries, you might also want to check @tshort’s early experimental work: [GitHub - tshort/StaticCompiler.jl: Compiles Julia code to a standalone library (experimental)](https://github.com/tshort/StaticCompiler.jl)

which is an interesting tree-shaking approach IIUC. I guess this is in principle possible for all type-stable functions.

---

<div class="post-metadata">

**Author:** ![jpsamaroo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jpsamaroo/32/46804_2.png) [@jpsamaroo](https://discourse.julialang.org/u/jpsamaroo)\
**Post date:** [September 8, 2020, 11:57am UTC](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290/36 "2020-09-08T11:57:58Z")

</div>

StaticCompiler.jl is much closer to what @Mayank_Gupta is describing, although dynamic linking still occurs, but it’s much closer to a standard C program in that there is no JIT. However, if you had the Julia code to replace libc, BLAS, and whatever else your code pulls in, you could technically compile a fully-static Julia binary with StaticCompiler, with a bit of work.

@RoyiAvital is correct that in order to be able to do this, you’ll need to define all “entry points” with their input types, and ensure that you: never do dynamic dispatch, replace dynamic dispatch with if-else, or implement a custom dynamic dispatch that doesn’t use a JIT. This is really the fundamental problem that needs solving, since dynamic dispatch comes up in a lot of places. Exceptions are also a similar problem that need to be solved by some similar mechanism, since they require allocations and non-linear control flow. Solving these sorts of problems would probably require generating a custom Julia runtime library that implements the basics of what the user’s program requires.

[Previous page](https://discourse.julialang.org/t/statically-compiled-and-statically-linked/12290.md?page=1)