<div dir="ltr">I'm using Docker to build and run my release (my company has tons of docker infrastructure)..<div><br></div><div>The official docker image looks like it builds erlang from source with `./otp_build autoconf`<br><div><br></div><div><a href="https://github.com/c0b/docker-erlang-otp/blob/master/20/Dockerfile">https://github.com/c0b/docker-erlang-otp/blob/master/20/Dockerfile</a><br></div></div><div><a href="https://hub.docker.com/_/erlang/">https://hub.docker.com/_/erlang/</a><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 24, 2018 at 7:27 AM, Roger Lipscombe <span dir="ltr"><<a href="mailto:roger@differentpla.net" target="_blank">roger@differentpla.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 24 April 2018 at 14:20, Vince Foley <<a href="mailto:vincefoley@gmail.com">vincefoley@gmail.com</a>> wrote:<br>
> Do you know of any documentation around building "unstripped" erlang<br>
> releases? This is my next step...<br>
<br>
</span>Don't strip them in the first place :)<br>
<br>
We build our Erlang/OTP using kerl, which we then embed into our<br>
release, which is then packaged as a .deb file, using the Debian tools<br>
(debbuild, etc.).<br>
<br>
It's the debbuild step that strips the binaries as they're put in the<br>
.deb file. We simply keep the unstripped beam.smp binary from before<br>
this happens. Do the ESL .deb files (assuming that's how you're<br>
installing Erlang) also contain stripped binaries?<br>
</blockquote></div><br></div>