[erlang-questions] Customizing Beam Build

[Joe Armstrong]

Everything would be a lot simpler if I could build a static version of erlexec

At some level abstraction we have a list of C files that must be compiled
and linked together.

If the C files and the header files were all in one directory this would be
easy - as it is the makefiles are generated automatically and the C
files that are needed to build the system are all over the place.

All I need is a makefile to build a static version of erlexec. It is not obvious
to me how to do this (otherwise I would have done it :-)

Cheers

/Joe



On Mon, Sep 25, 2017 at 9:32 PM, Tristan Sloughter <t@REDACTED> wrote:
> I like the idea of easily built static builds but for dealing with
> releases being messy (if I'm understanding what you mean) is something
> that may be solved simply with existing tools like makeself:
>
> http://makeself.io/
>
> --
>   Tristan Sloughter
>   "I am not a crackpot" - Abe Simpson
>   t@REDACTED
>
> On Sun, Sep 24, 2017, at 01:25 AM, 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.
>>
>> This is kind of terrible, as it requires I maintain a fork of OTP.
>> 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
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions