<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">"Any C program can be compiled statically ..."</div><div class="gmail_default" style="font-family:monospace,monospace">Would that it were so.  However,</div><div class="gmail_default" style="font-family:monospace,monospace">- you have to have statically linkable versions of<br></div><div class="gmail_default" style="font-family:monospace,monospace">  all the libraries you depend one, but you might</div><div class="gmail_default" style="font-family:monospace,monospace">  have been given only .so files</div><div class="gmail_default" style="font-family:monospace,monospace">- the operating system has to be willing to run</div><div class="gmail_default" style="font-family:monospace,monospace">  statically linked programs.  My preferred operating</div><div class="gmail_default" style="font-family:monospace,monospace">  system stopped shifting libc.a and the like years</div><div class="gmail_default" style="font-family:monospace,monospace">  ago, which annoyed me greatly at the time.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">One way to package everything up so that it appears to</div><div class="gmail_default" style="font-family:monospace,monospace">someone installing it as a single file and you are</div><div class="gmail_default" style="font-family:monospace,monospace">protected to some extent from clashes whether your</div><div class="gmail_default" style="font-family:monospace,monospace">dependencies and others' is to use a container image.</div><div class="gmail_default" style="font-family:monospace,monospace">I know, bloat upon bloat.  Feh!</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 3 Aug 2020 at 12:14, Dmytro Lytovchenko <<a href="mailto:dmytro.lytovchenko@gmail.com">dmytro.lytovchenko@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Any C program can be compiled statically unless it relies on some dynamic loading as part of its work.</div><div>The Problem is that <b>erl </b>and few other small tool programs are launching `beam.smp` as a part of operation, and compiling each of them statically will result in a pile of multi-megabyte executables.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 3 Aug 2020 at 01:13, Grzegorz Junka <<a href="mailto:list1@gjunka.com" target="_blank">list1@gjunka.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is it possible to compile Erlang Beam statically so that when I am doing <br>
a release it doesn't require any dynamically loaded libraries on the <br>
host to which the release is being deployed? I was trying the various <br>
configure options but the compilation was failing (for various reasons, <br>
mostly missing or conflicting function signatures). I could try again <br>
and post exact errors but would prefer to start with a tried and tested <br>
set of options.<br>
<br>
GrzegorzJ<br>
<br>
</blockquote></div></div>
</blockquote></div>