Cosmopolitan Erlang: build once run anywhere - possible?

Chat / Discussions
1

By knitting together boot sequences in a magical way, one is able to run c executables on any platform.

https://justine.lol/ape.html

I was wondering if this could be used to make portable scripts for any beam language.
One can already see this concept in the wild: GitHub - burrito-elixir/burrito: Wrap your application in a BEAM Burrito!

But instead of having to target the system you want to run the script on, you could instead just configure it to be cosmopolitan and let it run everywhere.

Reading through the build system of erlang/otp I tried altering the CFLAGS and LIBS environment variables to possibly link all that is required of cosmopolitan, but then felt out of my depth in terms of compiling large C projects. Also I had doubts on whether or not it was even a possibility.

It was possible with Python: Python is Actually Portable so I would be curious if it would be possible for Erlang.

4 Likes
2

I think the ā€œrun anywhereā€ claim for
the jart/cosmopolitan C thing is a bit overblown.
For hardware, it lists only ā€œIntelā€ and ā€œAMDā€,
no mention of SPARC, MIPS, ARM v7, ARM v8, or
RISC-V (to mention hardware I have), or z/Series
or POWER (or even PowerPC).
For operating systems, there is no mention of
Solaris (or its sibling Illumos) or Raspbian.

If I wanted to compile C (or Rust or Go or D)
once and run it ā€œanywhereā€, Iā€™d look at emscripten
plus something like wasmer.
https://v8.dev/blog/emscripten-standalone-wasm#running-in-wasm-runtimes
(This still seems insane, even perverse, to me,
something a hacker on acid might have dreamed up,
but itā€™s real. Sober ANDF lost to a head trip.)

Erlang is intrinsically portable and so is most of
OTP; youā€™re just not going to get the benefit of the
JIT everywhere.

My own experience of porting things between POSIX
implementations is that itā€™s the things you donā€™t
expect to be porting problems that actually are.
The whereabouts of various files, for example.
Floating-point code failing mysteriously because
ā€˜long doubleā€™ is bigger than ā€˜doubleā€™ but some of
the C library functions that are supposed to work
with long doubles are mapped by the compiler to
the double versions. (I am sick and tired of having
to roll my own <math.h> functions.) libuuid missing
or incomplete. [If anyone can tell me a portable way
to find my machineā€™s MAC address, that would be a
kindness.] Files that are missing, in the wrong
place, or empty. Packages or commands that have been
dropped with no obvious replacement. Things that
are where they are supposed to be but just donā€™t
work for inexplicable reasons.

All of this is why containers are so popular.

4 Likes
3

Looks rather cryptic =)

We just put several architectures to our erlang build and have single distributive compiled for 4 architectures.