You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 4, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Dec 4, 2023. It is now read-only.
Binary builds for Apple Silicon M1 arm64-darwin-20 #309
This libv8 is of course a pain because of all the usual reasons (depot-tools and custom clang) but sqreen/ruby-libv8-node 15.0 built right away, and mini_racer (slightly patched to use that instead of this libv8) passes tests with flying colours.
There is a slight hitch with arm64 vs arm64e that I have not resolved yet and makes me uncomfortable publishing binaries right now.
I toyed with adding the M1 machine as a self-hosted GH Actions runner over there but without a proper virtualisation solution this means the runner has access to some personal files as well as my LAN.
There are a couple of snags such as this one (fixed somewhere on upstream v8 and node 15.3).
I'm doing a rebuild of libv8-node based on 15.5.1 (I know, 15.6.0 is just out), I'll publish that as a beta along with a branch on rubyjs/mini_racer to use that instead of libv8 for people to try.
Is this a problem with Apple Silicon, or arm in general, @lloeki?
In Docker for Mac on Apple Silicon, I get this (indicating on a problem around fetching source?!):
Installing libv8 7.3.492.27.1 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
current directory: /usr/local/bundle/gems/libv8-7.3.492.27.1/ext/libv8
/usr/local/bin/ruby -I /usr/local/lib/ruby/site_ruby/2.7.0 -r ./siteconf20210403-9-8a84ia.rb extconf.rb
creating Makefile
Traceback (most recent call last):
File "/usr/local/bundle/gems/libv8-7.3.492.27.1/vendor/depot_tools/fetch.py", line 23, in <module>
import json
ImportError: No module named json
/usr/local/bundle/gems/libv8-7.3.492.27.1/ext/libv8/builder.rb:83:in `block in setup_build_deps!': unable to fetch v8 source (RuntimeError)
from /usr/local/bundle/gems/libv8-7.3.492.27.1/ext/libv8/builder.rb:81:in `chdir'
from /usr/local/bundle/gems/libv8-7.3.492.27.1/ext/libv8/builder.rb:81:in `setup_build_deps!'
from /usr/local/bundle/gems/libv8-7.3.492.27.1/ext/libv8/builder.rb:40:in `build_libv8!'
from /usr/local/bundle/gems/libv8-7.3.492.27.1/ext/libv8/location.rb:24:in `install!'
from extconf.rb:7:in `<main>'
extconf failed, exit code 1
Gem files will remain installed in /usr/local/bundle/gems/libv8-7.3.492.27.1 for inspection.
Results logged to /usr/local/bundle/extensions/aarch64-linux/2.7.0/libv8-7.3.492.27.1/gem_make.out
An error occurred while installing libv8 (7.3.492.27.1), and Bundler cannot continue.
Make sure that `gem install libv8 -v '7.3.492.27.1' --source 'https://rubygems.org/'` succeeds before bundling.
@tisba That problem will be solved wit the move to libv8-node. You can try this PR.
yeah, I probably posted that too quickly, it makes no sense what I wrote in this context. Sorry for the noise.
But thank you, I'm already watching rubyjs/mini_racer#186 very closely! We have some issue which requires to pin mini_racer to an old version (see rubyjs/mini_racer#170). I haven't had the time to fully test rubyjs/mini_racer#186 if it really solves our issue with forking.
Activity
angellozano67 commentedon Jan 11, 2021
@lloeki Any luck? 😄
lloeki commentedon Jan 12, 2021
Very much so.
This libv8 is of course a pain because of all the usual reasons (depot-tools and custom clang) but sqreen/ruby-libv8-node 15.0 built right away, and mini_racer (slightly patched to use that instead of this libv8) passes tests with flying colours.
There is a slight hitch with arm64 vs arm64e that I have not resolved yet and makes me uncomfortable publishing binaries right now.
I toyed with adding the M1 machine as a self-hosted GH Actions runner over there but without a proper virtualisation solution this means the runner has access to some personal files as well as my LAN.
santostiago commentedon Jan 18, 2021
Hi @lloeki.
What's the proper way to install the gem libv8 on a M1 macbook pro?
I've been struggling to install it with no success so far.
Thank you 😊
lloeki commentedon Jan 18, 2021
There are a couple of snags such as this one (fixed somewhere on upstream v8 and node 15.3).
I'm doing a rebuild of libv8-node based on 15.5.1 (I know, 15.6.0 is just out), I'll publish that as a beta along with a branch on rubyjs/mini_racer to use that instead of libv8 for people to try.
lloeki commentedon Jan 18, 2021
@angellozano67 @santostiago Here goes (no strings attached, use at your own risk), see the PR desc for how to use it: rubyjs/mini_racer#186
[-]Binary builds for Apple Silicon M1 aarch64-darwin-20[/-][+]Binary builds for Apple Silicon M1 arm64-darwin-20[/+]tisba commentedon Apr 3, 2021
Is this a problem with Apple Silicon, or arm in general, @lloeki?
In Docker for Mac on Apple Silicon, I get this (indicating on a problem around fetching source?!):
lloeki commentedon Apr 6, 2021
@tisba That problem will be solved wit the move to libv8-node. You can try this PR.
tisba commentedon Apr 6, 2021
yeah, I probably posted that too quickly, it makes no sense what I wrote in this context. Sorry for the noise.
But thank you, I'm already watching rubyjs/mini_racer#186 very closely! We have some issue which requires to pin mini_racer to an old version (see rubyjs/mini_racer#170). I haven't had the time to fully test rubyjs/mini_racer#186 if it really solves our issue with forking.