[erlang-questions] Customizing Beam Build

Benoit Chesneau bchesneau@REDACTED
Mon Sep 25 21:13:47 CEST 2017


> On 24 Sep 2017, at 10:25, Sargun Dhillon <sargun@REDACTED> wrote:
> 
> I've customized my OTP build to have a custom Erlang build. The reason
> I've done this to begin the process of building a fully-self contained
> Erlang program. One of the biggest benefits of the infrastructure in
> Go is that they're fully self-contained statically linked binaries. In
> Erlang, although you can statically link beam itself, unfortunately,
> the releases themselves are messy, in that you have a lot of files and
> getting the execution environment right isn't always trivial.
> 
> Eventually, the purpose is to build an init system -- something that
> will be primarily used by sysadmin-types. These need to be statically
> linked, and often times, the file system isn't fully-functioning when
> they're starting.
> 
> I've done two things:
> 
> 1) I've modified the set of preloaded files in the VM. It would be
> really nice if there was a way to do this without forking OTP. I
> didn't add any existing beam files, but I just changed around some of
> the file, and code loading code to my need.

+1
> 
> 2) I've modified the final, linked product to include custom objects
> in the final ELF binary.

What files did you changed for it?
> 
> This is kind of terrible, as it requires I maintain a fork of OTP.

Is this something public?
> Does anyone have any recommendations for solving this problem another
> way?
> 
> My proposal would be to output a beam.a file with the requisite
> objects to build a BEAM installation. It would be valuable if I could
> statically link against this binary, and own main, if it had a
> separate entrypoint that I could then call into. I've toyed around
> with this, and for the unix build, it seems possible. Is there any
> reason why Erlang isn't distributed this way already?
> 
> If there was a public API for extending the loader, or adding
> preloaded modules via sections, I imagine that solving (1) would be
> easy as well.
> 
> Is anyone open to accepting this upstream if the work is done?
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions




More information about the erlang-questions mailing list