Apple Silicon Erlang 23.2.1 not compiling bcrypt_elixir properly. I think

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.

1 Like

Brill. Thanks. I’ll pop over there and see what I can see.

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.

9 Likes

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! :slight_smile:

I had posted a previous solution which was only a temporary one. The error resurfaced after some time. To get rid of it,

  • rm -rf deps _build
  • mix deps.get
  • mix deps.compile

Do these steps from a separate Silicon terminal instance.

I had the Intel version of NeoVim running. I installed the latest Apple Silicon one, followed the above steps and voila the error went away.

I just ran into this, because I switched to iTerm2 and for whatever reason that defaults to launching in x86 mode.

You can change this in the menu: iTerm2 → Preferences → Profiles → General and change “Login Shell” to “Command” and then enter “arch -arm64 $SHELL”. No idea why this isn’t default…

2 Likes