Mix release requirements

I have compiled an elixir release, but am running into the following error:

/my_app/erts-11.0.3/bin/beam.smp: /lib64/libtinfo.so.6: no version information available (required by /my_app/erts-11.0.3/bin/beam.smp)
2020-09-08 13:17:33.469328
    args: [load_failed,"Failed to load NIF library /my_app/lib/crypto-4.7/priv/lib/crypto: 'libcrypto.so.1.1: cannot open shared object file: No such file or directory'","OpenSSL might not    format:     label:  be installed on this system.\n"]
"Unable to load crypto library. Failed with error:~n\"~p, ~s\"~n~s"
{error_logger,error_msg}

when running _build/prod/rel/my_app/bin/my_app start, even though I have OpenSSL 1.0.2k-fips installed on the machine.

I know that for an elixir release, the os doesn’t require elixir or erlang to be installed, but it looks like there are some os requirements, where can I find these requirements to run a release?

The full problem trying to solve is described here: https://stackoverflow.com/questions/63796472/mix-release-on-amazon-linux-2

I’m not sure if this is the correct place to ask this question, but any help or pointers as to what to try next would be greatly appreciated.

https://hexdocs.pm/mix/Mix.Tasks.Release.html#module-requirements

1 Like

Well, as it is written in the error - you need OpenSSL 1.1 on the target machine.

I managed to get it working, see solution here: https://stackoverflow.com/a/63811993/4699289.

Building the release on a similar machine to the one we will run it on seems to have resolved the problem.

I installed openssl 1.1 and experienced the same problem.

I’m not sure if this is a satisfying solution though, I’m open to a more elegant way of solving this.

This is a requirement of OTP releases, you need to build them on a machine that uses the same set of libraries than your target, in the same versions.

1 Like

This is how dynamic linking works:

  • you either make sure the part you distribute will link with the target environment
  • or you distribute all the libs, which is not different from static linking.

In the second way the risk is if there is a security issue in the lib the standard system upgrade will not cover you.

I always build the release again where it will run. It is fast enough and avoids all the linking problems and run time config problems

2 Likes