[erlang-questions] Customizing Beam Build

[Sargun Dhillon]

On Mon, Sep 25, 2017 at 12:13 PM, Benoit Chesneau <bchesneau@REDACTED> wrote:
>
>> 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?
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
>> 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
>