-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Libv8::Node::Paths with RubyGems >=3.3.21 on *-linux-gnu platforms (Ported to current master) #52
base: master
Are you sure you want to change the base?
Conversation
- Add make targets for local building and testing This is especially useful for building and testing on Darwin - Split makefile in two: one direct and one for docker This is necessary because direct targets and dockerized targets overlap on Linux. - Fix a few Dockerfile oversights due to updates in libexec
- arm64-darwin from x86_64-darwin (also added to CI) - x86_64-darwin from arm64-darwin - x86_64-linux from aarch64-linux
Use `xargs` to build the `ar` command line instead of running `ar` manually to reduce startup costs. Build the symbol table after adding each file instead of continually rebuilding it.
* Running libv8 on GraalVM LLVM is unlikely to ever work, instead using Graal.js makes more sense. This is already the case in mini_racer. libv8-node is a necessary dependency of mini_racer on CRuby, so for TruffleRuby the extconf.rb simply creates a dummy Makefile.
Skip compilation on TruffleRuby
This fixes an issue where functions that require ICU data segfault the process due to an unexpected lack of ICU data. The actual ICU data is provided by the icudt71_dat object.
Linking on Linux currently errors with `undefined reference to `'dlsym'`
(including our codespace)
and one that supports the newer cmake.
Alpine Linux's `ar` program doesn't support having objects with the same name in the archive twice, so we have to use the GNU extension for including paths. This commit *should* honestly be split into multiple separate commits, but unfortunately pretty much all of these changes have to be applied as a unit or a build step fails.
Add cpp test, fix locale issues and fix CI issues
RubyGems 3.3.21 changed the value format of `Gem::Platform.local` for Ruby configured with `*-linux-gnu` as the platform name. ```console $ ruby -ve 'p Gem::VERSION; p Gem::Platform.local.to_s' ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [x86_64-linux-gnu] "3.3.20" "x86_64-linux" $ ruby -ve 'p Gem::VERSION; p Gem::Platform.local.to_s' ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [x86_64-linux-gnu] "3.3.21" "x86_64-linux-gnu" $ ruby -ve 'p Gem::VERSION; p Gem::Platform.local.to_s' ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [x86_64-linux-gnu] "3.3.24" "x86_64-linux-gnu" ``` As you can see, it now has the `-gnu` prefix and `Libv8::Node::Paths.object_paths` thus has it when the built binary actually lives in the directory `x86_64-linux`, breaking the build of the gems like mini_racer on those platforms. [`RUBY_TARGET_PLATFORM` is set to `*-linux`](https://github.com/knu/libv8-node/blob/ad9105562185571f7b486f7770986f6a160318b2/libexec/platform#L28-L29), so `Libv8::Node::Paths.platform` needs to align with that. Ported forward by @MaZderMind
Jumping in here as this is now blocking my deployment/upgrade plan to move to Ruby 3.2. I see that updates are being made to the repo, which is awesome!! However the PR this is based on has been sitting there for over two years. Sorry if that across as judgy, I don't mean it too. Just trying to understand if this can be merged at the next opportunity or do I need to figure out how to fork this and build it myself so that I can continue to move forward. |
Ubuntu 24.04 is the oddball here (not that it's incorrect to have the
Unfortunately Debian Bookworm is a bit lagging and its rubygems cannot be
EDIT: Heh, actually rubygems is bumped on Sid yet it still gives a non-
Interestingly enough, Docker Hub Ruby images which are Debian Bookworm based have a non-
Similarly the ruby-lang.org official images are Ubuntu-based but do not have the
ArchLinux has no
NixOS has no
"has been sitting there" stings a little :( but I understand the frustration. It may look like a simple one line change but this change has rippling consequences on small but important details† so that it really works everywhere on every combination. And then it's a bit painful to build and publish all binary artifacts. † Some time ago I started a refactoring of the build process to move away from shell to Ruby in order to be much more DRY.
If you want to go this route to immediately unblock you:
And it'll build from source. But I'll try to address it in some way in the coming weeks. |
@lloeki , first and foremost, thank you for your quick reply, and can certainly wait a few weeks if that is what it takes to get this merged into the main branch and released. It seems to me that the disconnect is that the libv8 library produces a Maybe I'm being too simple here and missing what you speak about regarding Regardless, if this can be fixed with the published library, that is awesome and will save me time from setting up local environments to do the build. |
I'll carve out some time to have a proper fix.
Of course, I am very mindful of that. |
@lloeki coming back around and checking on this as my previous project is done and would like to pick this work back up. I see some activity on other PRs, so is this resolved or still needs to be worked on? |
RubyGems 3.3.21 changed the value format of
Gem::Platform.local
for Ruby configured with*-linux-gnu
as the platform name.As you can see, it now has the
-gnu
prefix andLibv8::Node::Paths.object_paths
thus has it when the built binary actually lives in the directoryx86_64-linux
, breaking the build of the gems like mini_racer on those platforms.RUBY_TARGET_PLATFORM
is set to*-linux
, soLibv8::Node::Paths.platform
needs to align with that.Ported forward from #36 by @MaZderMind