Releases without ERTS / Cross compiling

Questions / Help
1

I have been bitten by an issue with erts in a release, when one version of erts linked to libtinfo.so.5 and my server had libtinfo.so.6. Whatever, I recompiled.

Just wondering - in theory, if I don’t use NIFs, and have an archive of different versions of erts compiled for different os/architectures, and I match the same version of erts, I could create a release on (say) arm, copy it to x86, replace the erts folder, and it should be ready to go? or are there other things to keep in mind?

Because I was wondering if we couldn’t just share a bunch of pre-compiled ertts versions, and wget them on install…

2

If you don’t have any other native dependencies like NIFs then this does indeed work. That’s why include_erts for relases lets you specify not just a boolean, but also a path to custom erts folders.

1 Like
3

I’m realizing that it’s not that easy, because a lot of libraries have NIFs. For example, on a run-of-the mill Phoenix app, under myapp/lib, I’m finding:

[root@c9erl2 lib]# tree . -P '*.so' --prune
.
├── asn1-5.0.21
│   └── priv
│       └── lib
│           └── asn1rt_nif.so
├── crypto-5.1.3
│   └── priv
│       └── lib
│           ├── crypto_callback.so
│           ├── crypto.so
│           └── otp_test_engine.so
└── runtime_tools-1.19
    └── priv
        └── lib
            ├── dyntrace.so
            ├── trace_file_drv.so
            └── trace_ip_drv.so

And of course those won’t work on different architectures. OTOH, those files seem to be a part of the Erlang distribution itself, so maybe those .so files could overwrite the ones that are in my application’s lib?

4

Burrito recompiles NIFs for the target architecture using Zig (i.e. Clang). You might take some inspiration from there.