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
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)
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.
@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?
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'
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_racer0.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.
Activity
lloeki commentedon Jun 21, 2021
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)
lloeki commentedon Jun 21, 2021
Cross-compiling builds correctly, but I hit a missing symbol error.
lloeki commentedon Jun 21, 2021
It seems compilation was partial, the intermediate
libv8_monolith.atarget might have been insufficient for cross-compilation to fully proceed (e.gapi.ofromv8_base_without_compilerwas only present inobj.hostand absent fromobj.target), but running a fullmakeproduced all the required.oinobj.target.tisba commentedon Jun 21, 2021
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.
lloeki commentedon Jun 21, 2021
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.
lloeki commentedon Jul 12, 2021
@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-linuxdown the summary page and try it out as you did over there?tisba commentedon Jul 12, 2021
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.lloeki commentedon Jul 13, 2021
There's another build based on 16.4.2 over there: https://github.com/sqreen/ruby-libv8-node/actions/runs/1023202498
tisba commentedon Jul 13, 2021
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.gemand rungem generate_index(both natively on M1 and x86 Ruby 3.0.2 or viadocker run -it --rm -v "$(pwd)":/app -w /app ruby:3.0.2) and still getting the same error...To sanity check, I downloaded https://rubygems.org/downloads/rails-6.1.4.gem and
gem generate_index(andgem unpack) works. Does this work for you, @lloeki? What am I missing?ruby --version3.0.2p107gem --version3.2.23tisba commentedon Jul 31, 2021
Any ideas, @lloeki?
lloeki commentedon Oct 13, 2021
Sorry for the delay @tisba, I did not have a moment to look at this but I'm not forgetting about it!
lloeki commentedon Oct 18, 2021
@tisba I pushed some 16.10.0 gems and updated the mini_racer PR.
tisba commentedon Oct 20, 2021
System info:
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.rbproduces a segfault.fork.rb
Full Output
Removing the
forkworks fine.lloeki commentedon Oct 22, 2021
Thanks. This is probably due to rubyjs/mini_racer#170, as there was no development yet to use the new single threaded mode.
tisba commentedon Oct 22, 2021
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_racer0.2.15where this is not a problem. The main issue is, that if you fork anywhere, even unrelated tomini_racerusage, the problem is triggered.Back to topic: I'll try to run our large internal test suite against this build later.
tisba commentedon Jan 18, 2022
For reference: mini_racer 0.6.2 with
MiniRacer::Platform.set_flags!(:single_threaded)works now even with forking and onaarch64-linux,x86_64-linux,arm64-darwin21andx86_64-darwin21.I think what is "missing" for Linux ARM targets is mostly musl libc builds.