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

1 Like

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…


same issue - with SQLite blowing up with errors on an Apple Silicon (recompiled with elixir 1.13)
Solution for me:

most important part: is to do the following in a vanilla window (not iTerm!)

- rm -rf _build/*
- rm -rf deps/*
- mix deps.get
- mix deps.compile

and poof - compilation errors went away. Can now go back to running iex in an iTerm window no problem.

1 Like

Is there no way to run vscode in arm mode?

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.

This was the solution for me.

I’m having the same issue for some reason.

I’ve tried some of the solutions above, but am not sure if they’re working.

I also have bcrypt as a dependency, so I verified the architecture of the file as such:

$ file _build/dev/lib/bcrypt_elixir/priv/
_build/dev/lib/bcrypt_elixir/priv/ Mach-O 64-bit dynamically linked shared library arm64

So that seems to be fine.

I checked the architecture of my shell as well:

$ arch

I’ve compiled my project on my M1 and it took 9 minutes and change. On my x86 machine it took 50 seconds and change.

Okay I managed to get it working by simply completely reinstalling Elixir and Erlang.

brew remove erlang
brew remove elixir 
brew cleanup
brew install elixir

All is well now!

1 Like

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.

This was the trick for me as well on a new M1 Macbook Pro