BUG?: Bump mini_racer from 0.4.0 to 0.5.0 getting compile errors

[bf4]

I see them in the GitHub Actions as well. Not sure exactly what caused it, but didn't see an existing issue so reporting

e.g. https://github.com/rubyjs/mini_racer/runs/4174922268?check_suite_focus=true

building against Ruby 2.7.2, heroku buildpack running on the heroku/heroku:18-build image and node 10.15.3

(
  export HEROKU_STACK="18"
  export ruby_version="2.7.2"
  echo "https://heroku-buildpack-ruby.s3.amazonaws.com/heroku-${HEROKU_STACK}/ruby-${ruby_version}.tgz"
  export node_version="10.15.3"
  echo "https://s3pository.heroku.com/node/v${node_version}/node-v${node_version}-linux-x64.tar.gz"

)

stacktrace from circleci

seems to be specific to libv8-node-15.14.0.0 -> libv8-node-16.10.0.0 requires I install node 16.13.0? (nope, that didn't work)

Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

current directory:
/root/server/vendor/bundle/ruby/2.7.0/gems/mini_racer-0.5.0/ext/mini_racer_extension
/tmp/buildpack/ruby/ruby-2.7.2/bin/ruby -I
/tmp/buildpack/ruby/ruby-2.7.2/lib/ruby/2.7.0 -r
./siteconf20211111-3208-urf2xb.rb extconf.rb
checking for -lpthread... yes
creating Makefile

current directory:
/root/server/vendor/bundle/ruby/2.7.0/gems/mini_racer-0.5.0/ext/mini_racer_extension
make "DESTDIR=" clean

current directory:
/root/server/vendor/bundle/ruby/2.7.0/gems/mini_racer-0.5.0/ext/mini_racer_extension
make "DESTDIR="
compiling mini_racer_extension.cc
mini_racer_extension.cc: In function 'void* gvl_ruby_callback(void*)':
mini_racer_extension.cc:1255:92: warning: 'VALUE
ruby::backward::cxxanyargs::rb_rescue2(VALUE (*)(...), VALUE, VALUE (*)(...),
VALUE, ...)' is deprecated: Use of ANYARGS in this function is deprecated
[-Wdeprecated-declarations]
RUBY_METHOD_FUNC(rescue_callback), callback_data_value,
rb_eException, (VALUE)0);
^
In file included from
/tmp/buildpack/ruby/ruby-2.7.2/include/ruby-2.7.0/ruby/ruby.h:2863:0,
from
/tmp/buildpack/ruby/ruby-2.7.2/include/ruby-2.7.0/ruby.h:33,
                 from mini_racer_extension.cc:2:
/tmp/buildpack/ruby/ruby-2.7.2/include/ruby-2.7.0/ruby/backward/cxxanyargs.hpp:222:1:
note: declared here
 rb_rescue2(type *q, VALUE w, type *e, VALUE r, ...)
 ^~~~~~~~~~
linking shared-object mini_racer_extension.so
g++: error:
/root/server/vendor/bundle/ruby/2.7.0/gems/libv8-node-16.10.0.0-x86_64-linux-musl/vendor/v8/x86_64-linux/libv8/obj/libv8_monolith.a:
No such file or directory
Makefile:260: recipe for target 'mini_racer_extension.so' failed
make: *** [mini_racer_extension.so] Error 1

make failed, exit code 2

Gem files will remain installed in
/root/server/vendor/bundle/ruby/2.7.0/gems/mini_racer-0.5.0 for inspection.
Results logged to
/root/server/vendor/bundle/ruby/2.7.0/extensions/x86_64-linux/2.7.0/mini_racer-0.5.0/gem_make.out

An error occurred while installing mini_racer (0.5.0), and Bundler
cannot continue.
Make sure that `gem install mini_racer -v '0.5.0' --source

[tsugimoto]

You're Fetching and Installing libv8-node 16.10.0.0 (x86_64-linux-musl), so I suppose it's likely a duplicate of #218

[hmdne]

Also got this. But maybe I have something to add: it only happens on Ruby 2.7 and 2.6, not on 3.0.

See: https://github.com/opal/opal/runs/4202357932

[bf4]

@tsugimoto I saw #218 but since it's a different error, I wasn't confident it was the same issue, even if the result is the same. Thanks for cross-linking though

[lloeki]

Definitely looks like the same root cause, you can see things being mixed up here:

/root/server/vendor/bundle/ruby/2.7.0/gems/libv8-node-16.10.0.0-x86_64-linux-musl/vendor/v8/x86_64-linux/libv8/obj/libv8_monolith.a:

Also got this. But maybe I have something to add: it only happens on Ruby 2.7 and 2.6, not on 3.0.

With each Ruby version the vendored rubygems+bundler get updated. Can you update your rubygems+bundler and see if the issue persists?

[hmdne]

Thank you @lloeki. We were locking an outdated bundler version in our GitHub Actions due to an earlier issue with libv8. See: opal/opal#2360

[dspaeth-lp]

@lloeki

I got this error too. Steps to reproduce:

> docker run -ti  -w /usr/src/app --entrypoint /bin/sh ruby:2.7.4-alpine 
> apk update && apk add --no-cache build-base 
> gem update --system; gem install bundler
> bundle init
> echo "gem 'mini_racer', '0.5.0'" >> Gemfile 
> bundle

=> g++: error: /usr/local/bundle/gems/libv8-node-16.10.0.0-aarch64-linux/vendor/v8/aarch64-linux-musl/libv8/obj/libv8_monolith.a: No such file or directory

but it has to be

/usr/local/bundle/gems/libv8-node-16.10.0.0-aarch64-linux/vendor/v8/aarch64-linux/libv8/obj/libv8_monolith.a

aarch64-linux-musl => aarch64-linux

0.4.0 works

> docker run -ti  -w /usr/src/app --entrypoint /bin/sh ruby:2.7.4-alpine 
> apk update && apk add --no-cache build-base 
> gem update --system; gem install bundler
> bundle init
> echo "gem 'mini_racer', '0.4.0'" >> Gemfile 
> bundle

Edit: for libv8-node-15.14.0.1 the created lib is /usr/local/bundle/gems/libv8-node-15.14.0.1-aarch64-linux-musl/vendor/v8/out.gn/libv8/obj/libv8_monolith.a

[lloeki]

I'm going to try creating a fat gem which includes both linux and linux-musl libs (which I don't quite like since it doubles the gem size, but even when I get to fix the root rubygems/bundler issue old versions of these would still be affected)

[rusterholz]

Is there a fix for this? This is still happening with v0.6.0 as well.

[ZimbiX]

I think this may actually be a bug with the libv8-node gem instead, since installing that directly picks the musl version:

➜ gem install libv8-node              
Successfully installed libv8-node-16.10.0.0-x86_64-linux-musl
1 gem installed

I'm on Arch, which I don't think uses musl, and I haven't noticed musl in a gem install log before. That's not right, is it?

[ZimbiX]

Sorry, I should have read more of the context: https://github.com/rubyjs/libv8-node/issues/5, https://github.com/rubygems/rubygems/issues/3174. The bug lies in rubygems. A fix was merged (https://github.com/rubygems/rubygems/pull/4082), with a second rubygems PR outstanding (https://github.com/rubygems/rubygems/pull/4488).

Despite that second PR not being merged/released yet, simply updating rubygems allows me to successfully install the gem now: :tada:

➜ gem update --system  
[...]

➜ gem --version        
3.3.4     

➜ gem install libv8-node              
Successfully installed libv8-node-16.10.0.0-x86_64-linux
1 gem installed

➜ gem install mini_racer              
Building native extensions. This could take a while...
Successfully installed mini_racer-0.6.1
1 gem installed

Edit: Bundler still uses the wrong version - hence the second PR

[wwahammy]

@lloeki thanks so much for all the work you've done here. Like I asked on the other repo, is there anything I can do to help fix this? It's not fair to put all this on you but I'm not sure on what needs to be done or how I can help.

[tisba]

@bf4 can you check again against the latest mini_racer version? Also make sure to update rubygems and bundler.

A lot of related issues were solved by updating Rubygems and bundler and making sure the the right platforms are added to Gemfile.lock (via bundle lock --add-platform). From my understanding the outstanding rubygems issue/PR is about supporting multiple libc variants at the same time. So unless you need to support that in your projects, you should be good now.

[lloeki]

A lot of related issues were solved by updating Rubygems and bundler and making sure the the right platforms are added to Gemfile.lock (via bundle lock --add-platform)

Correct, but also, make sure to remove any platform-mismatched gem that may have been erroneously installed previously, otherwise bundler may be lazy and pick those up instead of hitting rubygems.org again. In some cases bundler was being stubborn and I've had to install the gem first with gem install, then proceed with bundle install.

From my understanding the outstanding rubygems issue/PR is about supporting multiple libc variants at the same time

It would indeed, but it should also helps in some corner cases e.g:

a) one created the lockfile on another platform than linux and did not run bundle lock --add-platform b) one is on either linux (gnu) or linux-musl and the lockfile does not exist yet c) a linux-musl gem on linux (gnu) cannot work, but could be picked up if it is previously installed for whatever reason

[schneems]

This isn't a bug in mini racer or in Heroku. This is a bug in bundler.

Make sure you run:

bundle lock --add-platform x86_64-linux

Then add the results to git before you try to deploy again. Previously bundler would raise an error if you tried deploying to a linux target without the linux platform locked. It looks like there's been a regression and that error is no longer raised. If that error still existed it would prevent this problem from happening as it wouldn't even let you try to bundle install without the correct platform being listed.

[tisba]

I've added a PR to add an installation troubleshooting section to the README: https://github.com/rubyjs/mini_racer/pull/240.

[wanlinwang]

gem install mini_racer

Sorry, I should have read more of the context: rubyjs/libv8-node#5, rubygems/rubygems#3174. The bug lies in rubygems. A fix was merged (rubygems/rubygems#4082), with a second rubygems PR outstanding (rubygems/rubygems#4488).

Despite that second PR not being merged/released yet, simply updating rubygems allows me to successfully install the gem now: 🎉

➜ gem update --system  
[...]

➜ gem --version        
3.3.4     

➜ gem install libv8-node              
Successfully installed libv8-node-16.10.0.0-x86_64-linux
1 gem installed

➜ gem install mini_racer              
Building native extensions. This could take a while...
Successfully installed mini_racer-0.6.1
1 gem installed

Edit: Bundler still uses the wrong version - hence the second PR

Thank you. It works.

[evolve2k]

Workaround. Resolved by upgrading from ruby 2.7 to ruby 3.0

[isankadn]

This worked for me.

gem install libv8-node -v '16.17.0.0' --platform 'x86_64-linux-musl' gem install mini_racer -v '0.6.1'

[lloeki]

gem install libv8-node -v '16.17.0.0' --platform 'x86_64-linux-musl'
gem install mini_racer -v '0.6.1' 

This works by happenstance because bundler kind of favours locally installed gems but it does not guarantee resolution and in some cases bundler (at least some versions) may pick another platform and still download another gem. If you're on musl and using bundler you should really:

bundle lock --add-platform x86_64-linux-musl
bundle lock --add-platform aarch64-linux-musl # if you have an expectation of using some ARM machines such as via Docker for Mac on Apple Silicon
# also do any other platform you may use e.g x86_64-darwin and  arm64-darwin