Problems deploying argon2_elixir

I managed to compile it after updating Erlang / OPT to version 20.

The problem people are reporting is that their dev builds work, but the production build doesn’t, and it seems they’re using Distillery.

Just want to chime in and say that I’ve reviewed the thread, and I don’t believe the issue lies with Distillery. If there was a general issue with NIFs, we’d see it in other cases, but we don’t. Rather curiously, even between two very similar libraries (bcrypt_elixir and argon2_elixir), only the latter exhibits this behaviour. I’m suspicious that there is something wrong with the NIF code itself, but I haven’t had time to look at it, but the error definitely seems to indicate that the NIF is violating some invariant.

Can someone explain why would a dev build work, but a prod release fail please?
It really bothers me in a “Can I depend on this thing” kind a way

Many reasons, like if it builds a nif but not storing it in priv, not getting compiled, not getting copied into the release, etc… etc…

Wonderful
Is this a Distillery specific problem or release problem in general?

Releases in general, they are designed to be small packed distributions with no extra stuff.
It’s not even a problem, it is just by design, just all libraries should do things right or they break, expectedly. ^.^

You’re making the assumption that this is even caused by releases in the first place. Based on that thread, it’s not clear to me whether people are running into this issue because they are taking a release and dropping it on another host which is missing system dependencies, or same OS but different kernel versions, or different versions of ERTS. When it comes to NIFs, extra care is required, this is a downside of using NIFs, but the tradeoff of course is better performance. You have to make sure your dev and prod machines match OS, compatible kernel versions, matching system dependencies and versions (i.e. musl/libc, OpenSSL, etc.), and ensure that the NIF is compiled for a target triple which matches the host (i.e. deploying something compiled for a specific CPU will almost certainly break if dropped somewhere else, but typically targets aren’t specified to that degree unless you are compiling for embedded devices).

If all of these things have been covered and there is still an issue, then either the NIF is written incorrectly, or there is a new edge case related to releases and NIFs. There are a very large number of projects deploying via Distillery/using releases, and I suspect the vast majority of them use at least one NIF - so if this was an issue with Distillery specifically, or even releases more generally, we would expect to have seen this come up already. Since that isn’t the case, I’m very suspicious that either one of the prerequisites have been missed, or there is a fundamental issue with the NIF itself, and based on the error we see, it could be either one of them. While I won’t be so foolish as to say that releases are infallible, they are certainly reliable enough that questioning them should be near the end of your list of suspects, just above Erlang/OTP itself.

Releases are a fundamental part of Erlang/OTP, and have been around since the very beginning - they’ve had over 20 years of use to uncover issues and get them resolved. Distillery itself is obviously newer than that, but has been around in some form or another for the past 4+ years and has seen a pretty wide array of deployments itself, we certainly would know if there was a reliability issue with NIFs by now

Quick update: I have made changes to the Makefile (removed some of the optimization options), and I’m waiting for feedback on those changes.

Problem solved

Simplifying the Makefile, along with a couple of other minor changes to the NIF code, (in version 1.2.13) seems to have solved the problem.

If anyone here was having issues creating a release, please update to 1.2.13.