Did anyone work on/with building Erlang releases that work on multiple architectures? It would probably contain the beam files together with multiple architecture erlang runtimes and some code that automatically starts the right one (or a fat binary erlang runtime).
If we did, I missed it Pinging @MononcQc . We also have some people missing in this group on here. I’ll get this fixed up.
I’ve never worked on that, the only attempts I had at multi-builds was to just make releases with no ERTS (or C) in them and running them on a target system with all the files needed.
1 Like
I just didn’t know if you knew anything off the top of your head from previous meetings. I want to say Wojtek looked at this, but I can not ping him here because he has not made himself part of the EEF here.
Oh did this get limited scope because I used the EEF tag??
That is correct, only eef volunteers can see this. Might want to re-post.
Technically, we already have multi-release: normal beam.smp, frame-pointer enabled one beam.frmptr.smp, debug beam.debug.smp. These are called “flavours”. When I needed both x64 and ARM ERTS in a single package, I used that approach (but had to provide my own trampoline erl script that was detecting architecture).
There were a few gotchas:
- resulting package size was quite big (well over 200 Mb just for 3 ERTS flavours)
- you need to use statically linked NIFs (or, make trampoline rename *.so files, e.g. crypto.so, or fix the source code to use
load_nifwith a specific filename depending on the architecture)
1 Like