Do we need both bin/erl and bin/dyn_erl in Erlang/OTP?

Erlang/OTP Proposals Proposals: Ideas
,
1

Erlang/OTP 25 makes it so Erlang releases are relocatable by default. It does so by calling bin/dyn_erl --realpath. bin/dyn_erl is a version of bin/erl implemented in C.

When using reltool, you can also mark a release as relocatable (this is the default). Doing so makes it so bin/dyn_erl is used instead of bin/erl. However, I believe this option is no longer relevant from Erlang/OTP 25 and the whole code path could be removed.

If that’s the case: do we still need both bin/erl and bin/dyn_erl? It looks like we have two options:

  1. Remove bin/erl, rename bin/dyn_erl to bin/erl, and make it the actual entry point

  2. Keep bin/erl as is and trim down bin/dyn_erl functionality to be only about computing the real path (potentially renaming it to bin/erl_realpath or similar?)

Thoughts?

9 Likes
2

I wholeheartedly endorse this idea. Anything that simplifies releases and the amount of executables one has to figure out to start an Erlang VM is a good thing.

We’ve had our fair share of this figuring out how to build releases for GRiSP and it’s not trivial to understand.

5 Likes
3

Funny, I was going through old notes and ran into one to move relocatable option to systools instead of reltool so I could remove the code in relx that copies dyn_erl to erl – goal of not having to have relx manually tweak anything after including the runtime.

This would be an even better solution :slight_smile:

Though I just checked and we don’t use dyn_erl in the case of Windows.

1 Like