Static Erlang

[Dave Cottlehuber]

On Tue, 4 Aug 2020, at 19:33, Grzegorz Junka wrote:
> 
> On 04/08/2020 16:32, Łukasz Niemier wrote:
> >> Is it possible to compile Erlang Beam statically
> > Yes

Hi Grzegorz

As Max said, you'll find it almost impossible to not have
a dependency on libc and similar system libraries.

If your intent is (for example) to run your erlang app
inside a vanilla FreeBSD jail or system, Erlang releases
already do this - we ship several elixir and erlang apps
this way already, each into their own jails. Nothing other
than the base FreeBSD OS (and therefore libc) is required
 - not even security/openssl.

These are built during CI to output a standard FreeBSD
package, in our custom repo, and then `pkg install`. The
manifest tells FreeBSD to pull in any custom NIF dependencies
and everything Just Works. NB we're not building these
using the ports tree, but it's a handful of lines of
shell or Makefile to achieve this.

I can share more details of that offline if needed.

> Would you know the configure options that should work?

OTP does support static embedding of some libraries, I've
only done this for Windows, and not recently.

--disable-dynamic-ssl-lib

IIRC sometime around R14A this became the default. And
obviously with some work, you could add any additional
library using whatever tricks ERTS does already. But
I am not sure this is worth the effort? GRISP is the
ultimate expression of this, I suppose.

> >> so that when I am doing a release it doesn't require any dynamically loaded libraries on the host to which the release is being deployed?

Yes, so long as you accept your libc dependencies.

> I am not using NIFs. I am just interested in the Erlang runtime. And I 
> need to be able to run it directly on the host, so any containerization 
> won't help - I am assuming a bare host with no packages installed. 
> systemd maybe could be an option but this system doesn't use systemd, it 
> isn't even Linux but this detail shouldn't matter.

Here's a list of runtime dependencies for our app, they're all either
directly required by OTP release itself (ASN1, crypto) and if you're
not using those modules, wouldn't be needed either.

/usr/local/lib/eden/lib/asn1-5.0.12/priv/lib/asn1rt_nif.so:
	libc.so.7 => /lib/libc.so.7 (0x800247000)
/usr/local/lib/eden/lib/crypto-4.6.5/priv/lib/crypto.so:
	libcrypto.so.111 => /lib/libcrypto.so.111 (0x801000000)
	libc.so.7 => /lib/libc.so.7 (0x800247000)
	libthr.so.3 => /lib/libthr.so.3 (0x800690000)
/usr/local/lib/eden/lib/crypto-4.6.5/priv/lib/crypto_callback.so:
	libc.so.7 => /lib/libc.so.7 (0x800247000)
/usr/local/lib/eden/lib/crypto-4.6.5/priv/lib/otp_test_engine.so:
	libcrypto.so.111 => /lib/libcrypto.so.111 (0x801000000)
	libc.so.7 => /lib/libc.so.7 (0x800247000)
	libthr.so.3 => /lib/libthr.so.3 (0x800675000)

If you *choose* to include runtime_tools, you have a few more:

/usr/local/lib/eden/lib/runtime_tools-1.14/priv/lib/dyntrace.so:
	libutil.so.9 => /lib/libutil.so.9 (0x800673000)
	libdl.so.1 => /usr/lib/libdl.so.1 (0x80068b000)
	libm.so.5 => /lib/libm.so.5 (0x80068f000)
	libelf.so.2 => /lib/libelf.so.2 (0x8006c1000)
	libc.so.7 => /lib/libc.so.7 (0x800247000)
/usr/local/lib/eden/lib/runtime_tools-1.14/priv/lib/trace_file_drv.so:
	libutil.so.9 => /lib/libutil.so.9 (0x800675000)
	libdl.so.1 => /usr/lib/libdl.so.1 (0x80068d000)
	libm.so.5 => /lib/libm.so.5 (0x800691000)
	libelf.so.2 => /lib/libelf.so.2 (0x8006c3000)
	libc.so.7 => /lib/libc.so.7 (0x800247000)
/usr/local/lib/eden/lib/runtime_tools-1.14/priv/lib/trace_ip_drv.so:
	libutil.so.9 => /lib/libutil.so.9 (0x800675000)
	libdl.so.1 => /usr/lib/libdl.so.1 (0x80068d000)
	libm.so.5 => /lib/libm.so.5 (0x800691000)
	libelf.so.2 => /lib/libelf.so.2 (0x8006c3000)
	libc.so.7 => /lib/libc.so.7 (0x800247000)

This package is deployable on FreeBSD as a single archive, with no
additional dependencies, so long as you keep the ABI/architecture.

I can share more details of that offline if this is of interest.

If you're trying to do something more complicated, you're going
to need to share some more details on why this is absolutely
necessary. Perhaps the GRiSP team have more experience to share.

A+
Dave