[erlang-questions] Customizing Beam Build
Tue Sep 26 18:03:48 CEST 2017
On Mon, Sep 25, 2017 at 12:13 PM, Benoit Chesneau <> wrote:
>> On 24 Sep 2017, at 10:25, Sargun Dhillon <> 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.
>> 2) I've modified the final, linked product to include custom objects
>> in the final ELF binary.
> What files did you changed for it?
I redid a significant portion of ./erts/preloaded -- erl_prim_loader,
and prim_file. I also changed this mechanism to be able to add my own
files (modules) in as well. The second part of the compilation was
just done by modifying Makefiles "by hand".
>> This is kind of terrible, as it requires I maintain a fork of OTP.
> Is this something public?
Not yet. It's very much "builds for me" -- and nobody else.
>> Does anyone have any recommendations for solving this problem another
>> 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
More information about the erlang-questions