Erlang + OpenSSL love-hate relationship
I observe one of the issues above every single time when I need to use an older version of Erlang. It happens only for the aged ones, because they need OpenSSL 1.x.x and my system uses OpenSSL 1.1.x. In some cases, you will be able to install a compatibility package (e.g., that’s the case for Linux distributions), but in some cases, it does not help.
Why? Sometimes those backward compatible packages are not containing headers, or libraries are copied into strange, distribution dependent place which causes Erlang compilation process to fail.
Also, it is worth mentioning that you clutter your OS with older versions of unused libraries. Docker containers solve that issue, but you will face the same problem during compilation.
How bad is it? Let me drop just a few examples:
BEAM me up, Scotty!
Click and enter your email to get access to the usand and get notified whenever we publish a new blog post on our website.Subscribe me
Let’s tackle this issue once for all!
Following solution helps in all situations, so:
- when you use
kerlto manage multiple versions of Erlang VM,
- when you use
asdf-erlangto do the same thing,
- when you compile Erlang from source on your own.
erlang >= 20.0
It should work out of the box, with OpenSSL 1.1 available in the Linux distributions.
However, if by any chance you will see the same problems (but, e.g. with a different version of OpenSSL), instructions below will help you as well. This mechanism is generic because it combines compiling Erlang and OpenSSL on your own with the desired setup.
erlang < 20.0
Sigh. Here we go. I assume you jump here because you found one of those issues mentioned above. 🐼
First things first, you will need C compiler and following dependencies:
- Required utilities recommended by erlang.org.
Additional prerequisites for Linux are here.
Now we are ready.
Step 1: Prepare OpenSSL
We have to clone and compile OpenSSL locally:
Step 2: Parametrized compilation of Erlang
Now we are ready to build Erlang. We need to pass additional options to the configuration step. The mechanism
differs depending on the tool being used, but the general rule is the same - we need to point configuration step to the place
where we compiled OpenSSL in the previous step. We do that by parametrizing
kerl) it will look like this:
Depending on your operating system and expectations you may need to change the list of arguments - YMMV, I will leave it for you.
Now in the same shell session where we exported the variable, you should build the desired Erlang version. I will
kerl or manual building should work without any issues:
Step 3: Profit!
Outside of the achieved effect, the mechanism described above has one additional advantage - you can compile Erlang VM with any version of the OpenSSL as you have the control of the whole process. To be honest, this solution can be generalized to any library on which Erlang VM depends.
Veteran Elixir/Erlang Team Available
Are looking for Elixir or Erlang experts?
You are in the right place! We truly love working with that technology, and as a side effect, it turned out that we have mastered it.