Is it possible to statically compile libraries into erts itself?

I have a very vague (R14 timeframe) recollection of it being possible to statically compile libraries into erts itself. Not NIFs, and not requiring an external / dynamic .so.

Back in R14 days, it took over 20 hours to compile OTP, but now its only a few minutes.

This is already broadly possible with SSL & ZLIB I believe, at configure time,via --disable-dynamic-ssl-lib and --enable-builtin-zlib.

Is this possible today, in some more generic capacity?

I have a few things where shipping a nice phat erts + .ez jammed together would be really nice, and I can afford the up-front compile time impact, for the simplicity of a single binary. Tools like bakeware and burrito are nice, but don’t solve the NIF situation.

4 Likes

For what it’s worth, I have a lenghty script for building portable Linux binaries for a project of mine (ejabberd uses the same idea). The binaries have no external dependencies except for glibc 2.19+ (and the magic could easily be modified to link statically against Musl instead). The OTP ./configure flag --enable-static-nifs is used to avoid NIF .sos (mostly to avoid duplicating external library code into multiple .sos).

However, this doesn’t end up with a single binary, my goal is just portability by avoiding external dependencies. And as I said, the script is … lengthy.

2 Likes

We do this when cross-compiling the BEAM for GRiSP. See e.g. our cross-compilation configuration here.

It is a more involved build process including our own build tool and a custom toolchain.

2 Likes