[erlang-questions] Customizing Beam Build

Joe Armstrong erlang@REDACTED
Sun Sep 24 12:27:03 CEST 2017


This is great (I think) - if you've done what I think you might have done

Have you seen following this thread?

http://erlang.org/pipermail/erlang-questions/2017-September/093468.html

I posted a comment here:

http://erlang.org/pipermail/erlang-questions/2017-September/093496.html

If we can link all the DLL's to a single together with a small number
of precompiled
erlang modules then I think making stand-alone applications is doable.

I experimented with self-modifying code - you basically take the executable
and append some beam code at the end of the executable. The precompiled
part checks to see if any code has been added to the end of the executable
and if so loads and runs it.

The nice part about this is you can write the self-modifying part in Erlang.

What is needed is a script that can make a stand-alone program with a
number of precompiled erlang modules, say something like this:

    > make_stand_alone_executable x.erl y.erl z.erl  -start x -out prog

This would turn x.erl y.erl and z.erl into C (this is easy) then build
a stand alone
executable called prog.

The command "prog args" would start execution of x:main(args)

I thought to myself this must be possible since all the C code necessary
is available - the fact that erlexec is small and does not statically link
the emulator must have to do with the makefiles - Unfortunately I could
not easily figure out how the makefiles were constructed.

I tried to do this a while back - and remember there was one other
problem - the code in erlexec presupposes a bin directory (or
something like that)

There would be another problem with NIFs - since these are dynamically loaded
they would have to be statically linked instead.

If you can make a statically linked binary containing a small number of
pre-compiled beam files the rest should be easy. The only thing
to watch for is to make sure that that static binary does not require
and funny environment variables or directory paths to be set.

To me "stand alone" means "stand alone" (ie the program should not break if
you relocate it because you forgot to set some environment variable.

If you have the basis for a 'make_stand_alone_executable' script it would be
great - how to integrate this with all the autoconf stuff is a mystery to me.

Cheers

/Joe











On Sun, Sep 24, 2017 at 10:25 AM, 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.
>
> 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



More information about the erlang-questions mailing list