Open lloeki opened 3 years ago
Currently built manually inside an aarch64 Linux VM on a M1 Mac Mini. Appears to run fine on Linux on ARM hardware (Graviton) but has trouble at runtime on emulated machines (via qemu on x86 and/or docker's hyperkit on M1)
Cross-compiling builds correctly, but I hit a missing symbol error.
root@5e26cbbca17e:/mini_racer# bundle exec rake test
/usr/local/bin/ruby: symbol lookup error: /mini_racer/lib/mini_racer_extension.so: undefined symbol: _ZN2v82V818SetFlagsFromStringEPKcm
rake aborted!
root@5e26cbbca17e:/mini_racer# echo _ZN2v82V818SetFlagsFromStringEPKcm | c++filt
v8::V8::SetFlagsFromString(char const*, unsigned long)
It seems compilation was partial, the intermediate libv8_monolith.a
target might have been insufficient for cross-compilation to fully proceed (e.g api.o
from v8_base_without_compiler
was only present in obj.host
and absent from obj.target
), but running a full make
produced all the required .o
in obj.target
.
Currently built manually inside an aarch64 Linux VM on a M1 Mac Mini. Appears to run fine on Linux on ARM hardware (Graviton) but has trouble at runtime on emulated machines (via qemu on x86 and/or docker's hyperkit on M1)
Just a tiny remark: Docker for Desktop does also have experimental support for Big Sur/MacOS virtualization.framework. The same problem exists there though. Docker's hyperkit VM was/is based on hypervisor.framework.
Got a build and a gem working! Not publishing yet because things are not ready automation-side but testers are welcome to make themselves known.
@tisba I have Linux cross compilation to ARM on x64 CI working, see this run (there are some failures but they're on Darwin and Alpine, gnu/ARM passes!)
Before I pull the trigger and publish these, can you download the gem-16.3.0.0-aarch64-linux
down the summary page and try it out as you did over there?
For some reason I'm getting an error when I try to process the gem (gem generate_index
). I'll take a closer look later.
$ gem generate_index
ERROR: Unable to process /app/repo/gems/libv8-node-16.3.0.0-aarch64-linux.gem
"\xF7\xA0\aw\xB7\x83\xBBs" is not an octal string (ArgumentError)
/usr/local/lib/ruby/3.0.0/rubygems/package/tar_header.rb:129:in `strict_oct'
/usr/local/lib/ruby/3.0.0/rubygems/package/tar_header.rb:107:in `from'
/usr/local/lib/ruby/3.0.0/rubygems/package/tar_reader.rb:59:in `each'
/usr/local/lib/ruby/3.0.0/rubygems/package/tar_reader.rb:112:in `find'
/usr/local/lib/ruby/3.0.0/rubygems/package/tar_reader.rb:112:in `seek'
/usr/local/lib/ruby/3.0.0/rubygems/package.rb:544:in `read_checksums'
/usr/local/lib/ruby/3.0.0/rubygems/package.rb:604:in `block (2 levels) in verify'
/usr/local/lib/ruby/3.0.0/rubygems/package/tar_reader.rb:27:in `new'
/usr/local/lib/ruby/3.0.0/rubygems/package.rb:603:in `block in verify'
[…]
There's another build based on 16.4.2 over there: https://github.com/sqreen/ruby-libv8-node/actions/runs/1023202498
I'm not sure what I'm doing "wrong" 😞
I downloaded https://github.com/sqreen/ruby-libv8-node/suites/3216862858/artifacts/74504625 as gems/gem-16.4.2.0-aarch64-linux.gem
and run gem generate_index
(both natively on M1 and x86 Ruby 3.0.2 or via docker run -it --rm -v "$(pwd)":/app -w /app ruby:3.0.2
) and still getting the same error...
ERROR: Unable to process /app/gems/gem-16.4.2.0-aarch64-linux.gem
"f:bff<\xA2#" is not an octal string (ArgumentError)
/usr/local/lib/ruby/3.0.0/rubygems/package/tar_header.rb:129:in `strict_oct'
/usr/local/lib/ruby/3.0.0/rubygems/package/tar_header.rb:107:in `from'
/usr/local/lib/ruby/3.0.0/rubygems/package/tar_reader.rb:59:in `each'
/usr/local/lib/ruby/3.0.0/rubygems/package/tar_reader.rb:112:in `find'
/usr/local/lib/ruby/3.0.0/rubygems/package/tar_reader.rb:112:in `seek'
/usr/local/lib/ruby/3.0.0/rubygems/package.rb:544:in `read_checksums'
To sanity check, I downloaded https://rubygems.org/downloads/rails-6.1.4.gem and gem generate_index
(and gem unpack
) works. Does this work for you, @lloeki? What am I missing?
ruby --version
3.0.2p107gem --version
3.2.23Any ideas, @lloeki?
Sorry for the delay @tisba, I did not have a moment to look at this but I'm not forgetting about it!
@tisba I pushed some 16.10.0 gems and updated the mini_racer PR.
System info:
RUBY_VERSION : 3.0.2
RUBY_PLATFORM: aarch64-linux
MiniRacer::LIBV8_NODE_VERSION: ~> 16.10.0.0
Libv8::Node::VERSION: 16.10.0.0
Libv8::Node::NODE_VERSION: 16.10.0
Libv8::Node::LIBV8_VERSION: 9.3.345.19
I'm running this on Big Sur 11.6, Mac mini (M1, 2020).
Running the following script with docker run -it --rm -v "$(pwd)":/app -w /app ruby:3.0.2 ruby /app/fork.rb
produces a segfault.
Removing the fork
works fine.
Thanks. This is probably due to rubyjs/mini_racer#170, as there was no development yet to use the new single threaded mode.
Thanks. This is probably due to rubyjs/mini_racer#170, as there was no development yet to use the new single threaded mode.
Yeah I know, just wanted to check this too.
As I use mini_racer in a normal Rails application as part of the business logic, this is blocking us from updating from mini_racer
0.2.15
where this is not a problem. The main issue is, that if you fork anywhere, even unrelated to mini_racer
usage, the problem is triggered.
Back to topic: I'll try to run our large internal test suite against this build later.
For reference: mini_racer 0.6.2 with MiniRacer::Platform.set_flags!(:single_threaded)
works now even with forking and on aarch64-linux
, x86_64-linux
, arm64-darwin21
and x86_64-darwin21
.
I think what is "missing" for Linux ARM targets is mostly musl libc builds.
Possible on GHA via qemu and/or xbuild. Also available on Travis.
Considered targets: