I was using asdf to install the latest Apple Silicon compiled versions of Erlang and Elixir to use on a Phoenix project that employs the new gen-auth stuff.
When running elixir 1.11.2-otp-23 + Erlang 23.2.1 for Apple Silicon, bcrypt_elixir fails to compile, noting it needs Erlang 20 or better. The bcrypt.nif never gets created.
When I revert back to my last Intel version of Erlang, 23.0.3, I can rebuild the project and the bcrypt.nif gets created. Keeping Apple or Intel Elixir makes no difference. It comes down to the Erlang base system.
So, what comes next? The maintainer of bcrypt_elixir recommended I post here since it doesn’t seem to be his problem – maybe something with the elixir_make process? I admit I’m still a newbie in this ecosystem, so I’m at a roadblock for where to go to seek the knowledge to get this resolved. I expect I’m not the only person this will affect.
With bcrypt_elixir you’re not compiling elixir, but C. The error you posted in the github issue on for bcrypt_elixir does indeed suggest there’s some issue with the C related tooling, which may be something elixir_make can adjust for.
This where I admit I’m an idiot and post the solution for others who didn’t already figure this out.
This was a VSCode problem. Everything was working as intended, but a race condition of a sort was breaking my needed flow.
My VSCode was launched. It’s the intel build, and it’s running the ElixirLS extension (jakebecker version).
I knew I needed to rebuild, so I rm -fr my deps and _build directories.
When VSCode was running in the background, after I deleted the deps directory, it re-fetched the dependencies automatically. The Intel versions, however that works. Rebuilding resulted in the mismatched versions of the bcrypt_nif.so, and Phoenix freaked the hell out when I tried to do any user authentication.
When I completely quit VSCode and built from the terminal after deleting the deps and _build directories, everything fetched and elixir_bcrypt built for the proper architecture.
I didn’t realize that VSCode was using its spawned Intel beam process to correctly fetch those deps according to its architecture. I wanted to share in case someone else has a brain fart like I did. I’ll probably switch to the VSCode insiders arm64 version until the main release gets the Apple Silicon treatment. Or maybe it’s finally time to switch to emacs.
I just ran into this same issue. I build my project in Vagrant but I had left VSCode open looking at the shared folder, so it fetched the host OS NIFs when I was trying to build them inside Vagrant. Learned my lesson, close VSCode when building the release!
If you’ve never downloaded the universal build, you’ll probably need to do so. I don’t know if the built-in update mechanism will update your x86 build to the universal one. If you’re having problems like this, I suspect VSCode doesn’t change tracks automatically.
Sometimes it’s simply faster to start over rather than troubleshoot. (Tell that to the people who forgot to keep a reliable backup when the solution was to reformat their C: drive back in the day…)
As an aside, while I have nothing but love for homebrew, I recommend asdf-vm to manage your Erlang/Elixir installs. It makes it trivial to support multiple version targets for various projects I’ve been working on over the years. NodeJS, too.