nahoj
Erlang dependency compiled with wrong Erlang version
Hello, I’m a newcomer to both Elixir and Erlang and I’ve run into an issue and I hope someone here can help me.
When using mix compile I seem to be getting a compatibility error, that the beam file is compiled for a later version of the runtime system.
16:05:42.441 [error] beam/beam_load.c(184): Error loading module luerl:
This BEAM file was compiled for a later version of the runtime system than the current (Erlang/OTP 25).
To fix this, please re-compile this module with an Erlang/OTP 25 compiler.
(Use of opcode 181; this emulator supports only up to 180.)
A simple cleanup of deps/ and _build/ will recover from the issue, but that isn’t desired.
I’ve isolated it to only show up on Elixir version 1.15.x using below Erlang/OTP
mix --version
Erlang/OTP 25 [erts-13.2.2.3] [source] [64-bit] [smp:20:20] [ds:20:20:10] [async-threads:1] [jit:ns]
Mix 1.15.7 (compiled with Erlang/OTP 24)
I’ve created a sample repository https://github.com/JohanKarlbergg/01e3c763592bbc85568a28a81ae6f5f732d8d183f7f533080a0998e7229127fe and put a command in the README reproduce the issue.
I’ve tried to search for similar issues without success.
Most Liked
LostKobrakai
While it’s certainly to be preferred that’s not completely correct. You need that for elixir to integrate with OTP 25 features, but using an elixir version compiled with an older otp version should generally work.
Eiji
Because this is not considered as an issue. The message is clear enough and as you said there is solution of cleanup which you know without searching. In such case if people know something without searching they don’t create any issue and just your question is not common. ![]()
Keep in mind that on the forum many users reading your post have no idea how you think like they have no idea why recompiling all dependencies is not desired for you. As you said recompiling all dependencies is of course good idea and people do it by default in almost all cases - at least those I am aware of. However if for some reason you don’t want to compile all dependencies then you can simply recompile just one. ![]()
mix deps.compile dep_name --force
You need to improve your documentation research skills. What’s may be interesting is mix help task which lists all tasks available and mix help task.name which shows the documentation for said task. I believe that deps.compile is obvious naming, so there is no need to describe what it does. Finally the documentation in mix help deps.compile should be enough clear for you. ![]()
Personally I recommend reading documentation a lot. Of course not to remember everything, but to more or less know where you can find some information and also you may find lots of interesting things that would be helpful for you now or in near future and you were just was not aware of their existence. The common mistake is to not read Erlang documentation assuming that Elixir core is all what you need. For example I have found :erlang.term_to_binary/1 and :erlang.binary_to_term/1 very useful. This is pretty basic and simple to understand thing new developers have completely no idea about. ![]()
Edit: As @kokolegorille said firstly you need to fix the problem with your Elixir installation. After this you can use mix deps.compile to recompile only those dependencies you want.
kokolegorille
How did You install Elixir and Erlang? With asdf?
You have an Elixir version for OTP24, but You have OTP25
You need to change the Elixir version to be OTP 25
Latest for now is OTP 26…
Eiji
You need to use an Elixir version with -otp-25 suffix if you use Erlang version 25.
LostKobrakai
It’s “should” afaik. In the end elixir becomes precompiled beam files, which are forward compatible to newer OTP versions.
I also don’t think the issue here is due to the elixir installation being used. If you use OTP 25 and elixir compiled with otp 24, both won’t magically use a new opcode introduced in OTP 26. It’s more likely a mess either with switching OTP versions or even more with switching otp versions and having dependencies, which keep build artifacts within deps/ instead of only within _build/. That happens with some erlang dependencies (more likely on old ones though).
The stated cleaning of deps/ and _build resolving the issue would certainly favor that theory. Generally clearing _build should already be enough.







