ffi: 1.14.2: missing compatible arch in ffi_c.bundle on M1 Mac mini with system Ruby

@venkatasg Have to correct myself, the issue seems to be the version jekyll is depending on. Jekyll still depends on 1.13 while the support for M1 seems to have been implemented in 1.14. Unfortunately it seems the fix is not working as I am still getting the error with the newest version of jekyll which uses 1.14.

For now the only solution seems to be the rosetta workaround:

Install: arch -arch x86_64 bundle install Start: arch -arch x86_64 bundle exec jekyll serve

Got it to work by using system ffi :

brew install libffi
gem uninstall ffi
gem install ffi -- --enable-system-libffi

I’ve seen many solutions. Some install ffi via brew in x86_64 mode, others in native. None have worked for me.

There’s also the option of compiling yourself, although I don’t know all the steps and don’t think it helps.

Running in x86 (Rosetta) mode is not a solution and more a workaround. Native support would be much better.

Apple added deprecation notices to the system Ruby installation starting in 10.15 (Catalina). Fire up irb and you’ll see this:

WARNING: This version of ruby is included in macOS for compatibility with legacy software.
In future versions of macOS the ruby runtime will not be available by
default, and may require you to install an additional package.

I’m not entirely sure how users are supposed to know about this though, I just recall it being reported at the time. Might as well be on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying “Beware of the Leopard.”

@venkatasg you’re “using the system ruby and bundle” which goes against this recommendation and that of the article, which tells you to go to the Ruby site for installation options, not use the preinstalled one. Again I’m not faulting you here, it’s a frustrating/confusing situation for sure when these utilities are “available” but often ancient and/or broken.

~It might be a good idea to update the title of this bug to make abundantly clear we’re talking about the system Ruby installation.~ (update: 👍🏻)

@sanzaru could you provide the script you used? I can help file a radar and share the appropriate Open Radar here if no one is doing that.

Is there any obvious fix for RbConfig being wrong on native Ruby on M1?

Not that I know of. The only “solution” is to install your own ruby (e.g. via Homebrew) and use that. The binary from Apple is deprecated. I wrote an article about my findings, if you’re interested: https://medium.com/better-programming/ruby-on-apple-silicon-m1-macs-fb159849b2f5

I upgraded the Ruby to 3.0.2 with asdf as you can follow steps here.

After that I needed to update bundle,

bundle update
bundle add webrick

you can also follow steps described here.

As a result of that bundle exec jekyll serve works fine on M1 mac

After playing around a bit I found out that the pre-installed ruby on macOS seems to falsely recognize the CPU as x86, no matter what you tell it to do:

~ lipo -archs /usr/bin/ruby        
x86_64 arm64e
~ ruby -v                          
ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.arm64e-darwin20]
~ arch -c -arch arm64e ruby test.rb
OS: darwin20
CPU x86_64
Arch: universal-darwin20

So the problems seems to be more deeply than we thought and we might just have to wait for Apple to update the pre-installed ruby.

Was running similar problems with Flutter and cocoapods. From here, https://github.com/flutter/flutter/wiki/Developing-with-Flutter-on-Apple-Silicon the following worked for me:

sudo gem uninstall ffi && sudo gem install ffi -- --enable-libffi-alloc

Apple added deprecation notices to the system Ruby installation starting in 10.15 (Catalina). Fire up irb and you’ll see this:

WARNING: This version of ruby is included in macOS for compatibility with legacy software.
In future versions of macOS the ruby runtime will not be available by
default, and may require you to install an additional package.

I’m not entirely sure how users are supposed to know about this though, I just recall it being reported at the time. Might as well be on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying “Beware of the Leopard.”

That’s interesting. I didn’t know about this warning at all. Could be more transparent for devs…

@sanzaru could you provide the script you used? I can help file a radar and share the appropriate Open Radar here if no one is doing that.

Of course. It was quite simple:

require 'rbconfig'

OSVERSION = RbConfig::CONFIG['host_os']
CPU = RbConfig::CONFIG['host_cpu']
ARCH = RbConfig::CONFIG['arch']

puts "OS: #{OSVERSION}"
puts "CPU #{CPU}"
puts "Arch: #{ARCH}"

I found out that the RbConfig module (rbconfig.rb) seems to be the problem as it was compiled for x86 and therefore always returns that value when reading the module. Hope I can publish a detailed article about that, soon.

I guess we need to file a Feedback/Radar with Apple then? I might get around to it sometime, but I’ve never gotten any response on any of the feedbacks I’ve filed thus far, so I’ve learnt never to place high trust in that.

Should I close this issue?

What version did you install?

$ rbenv which ruby
/Users/kameliya/.rbenv/versions/2.7.2/bin/ruby
$ ruby -v
ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [arm64-darwin20]

For me, it seems that I got 2 different versions of ffi and it was choosing the bad one so first uninstall both: sudo gem uninstall ffi Then proceed with the above.

On my M1, I enabled rosetta on xcode and terminal, to support older projects. Then had to do this:

arch -arm64 brew reinstall libffi
gem uninstall ffi
arch -arm64 gem install ffi

PS: I’m using cocoapods from gem and not from brew.

I’ve seen many solutions. Some install ffi via brew in x86_64 mode, others in native. None have worked for me.

It seems one solution is to run whole terminal in Rosetta mode (go to apps -> tools -> terminal -> right click -> get info -> open using rosetta) and then install everything in that mode (I use XCode in rosetta and that works for my mobile dev env) - but personally I gave up on that idea - you have to juggle with arch and it’s becomes a pain quickly - and simply started running M1-incompatbile projects in docker container via docker compose - there is already m1 tech previews available and it’s pretty stable; everything else - I try to install natively - if it breaks - docker to the rescue; my 2-cents-workaround 🤷

I had these issue a few minutes ago. Sound weird, but the solution was to start Xcode. I updated Xcode a few days ago and the licence had to be acknoledged, after that I could run bundle install and ffi was installed without any issues.

Was running similar problems with Flutter and cocoapods. From here, https://github.com/flutter/flutter/wiki/Developing-with-Flutter-on-Apple-Silicon the following worked for me:

sudo gem uninstall ffi && sudo gem install ffi -- --enable-libffi-alloc

This did the trick for me! Thanks Stef!

I had an existing Jekyll project that hit the ffi issue. It was already placing all code into vendor/bundle

I was able to install a new libffi with brew, setup things to use it rather than the system version, and then the bundle install succeeded (which included the ffi gem).

brew install automake libffi pkg-config
...
export LDFLAGS="-L/opt/homebrew/opt/libffi/lib"
export CPPFLAGS="-I/opt/homebrew/opt/libffi/include"
bundle install

from an Above comment :

I upgraded the Ruby to 3.0.2 with asdf as you can follow steps here.

After that I needed to update bundle,

bundle update
bundle add webrick

you can also follow steps described here.

As a result of that bundle exec jekyll serve works fine on M1 mac

This worked for me! here’s how…

I’m using an Apple M1 Mac Mini , running Big Sur 11.6

some notes on the solution:

It was important for me to realize I was using zsh now, instead of Bash like I was used to on my old Mac laptop. This is a new default, so I installed Oh My Zsh to make things easier going forward for myself. ymmv.

Homebrew installation of ruby did me dirty because there was a command that is supposed to update the $PATH, but it wasn’t working.

This was due to homebrew some how, I forget now sorry I should have noted it… but anyways, I uninstalled the home-brew version of ruby.

No matter what with this home-brew version, when I typed ruby -v , it would tell me that I am using the 2.x.x version not the 3.x.x. This is the Mac OS default ruby version.

So I installed a fresh ruby after deleting the home-brew ruby. which ruby where ruby helped me here. It went from being in the something/homebrew/something/ruby location to the usr / myname / ruby location. Fresh install confirmed.

The next hurdle was how to tell the system to use this 3.x x version of ruby by default and not the 2.x.x oldie one.

For this, I installed a ‘manager’ called ‘asdf’, which allowed me to fix the issues with my $PATH. After following the asdf install instructions, what worked in the end was running asdf reshim ruby.

Then when I typed ruby -v it showed the correctt 3.x.x version. Hurray.

Then, with ruby working, I moved on to jekyll.

I followed this advice to uninstall my accidental jekyll installs just to start fresh to not mess myself up somehow. turns out I had a few extra installs so I nuked them all and followed the generic instructions to get my fresh install. I thought everything was done right but then I encountered this thread’s main topic, the issue with the m1 chip.

So after having installed jekyll, then Jekyll new mysitename , then cd mysitename

then

bundle update
bundle add webrick

then

bundle exec jekyll serve WORKED!!!

Thank you 😃

@mkocus: At least as of 2021-06-21: if you make sure to install ruby from homebrew, and make sure PATH points to this newer version of ruby (rather than the binary installed by default on macOS), installing packages that make use of ffi should work just fine. (At least I have not run into any problems).

You can put it in a file (e.g. call it arch.rb) and then run ruby arch.rb to get the results.

I’ve seen many solutions. Some install ffi via brew in x86_64 mode, others in native. None have worked for me. There’s also the option of compiling yourself, although I don’t know all the steps and don’t think it helps.

Running in x86 (Rosetta) mode is not a solution and more a workaround. Native support would be much better.

What’s so frustrating is some say that everything works fine, but don’t say whether they used the solution and/or workaround they used. So it’s been very frustrating. I was hoping for a constructive reply, but dismayed that even though I clearly said “in x86_64 mode” you’d have some subjective semantical objection to a word in the previous sentence. Anyway, it’s hard to tell if anyone has it working natively or not.

Any idea if there’s work on to fix it in the near future? I wish I could help, but I’m not familiar with this low level stuff at all.