rubyjs / libv8-node Goto Github PK

View Code? Open in Web Editor NEW

14.0 14.0 24.0 290 KB

Package libv8 from Node

License: MIT License

Ruby 28.49% Shell 48.21% Dockerfile 3.82% Makefile 6.92% CMake 4.73% C++ 6.84% C 0.98%

libv8-node's People

Contributors

Stargazers

Watchers

libv8-node's Issues

Relocation error on ruby 2.0, 2.1, and 2.2

linking shared-object sq_mini_racer_extension.so
65
/usr/bin/ld: /__w/AgentRuby/AgentRuby/vendor/bundle/ruby/2.0.0/gems/sq_mini_racer-0.3.1.0.0/ext/mini_racer_extension/vendor/libv8-node-14.14.0.0.beta2-x86_64-linux/vendor/v8/out.gn/libv8/obj/libv8_monolith.a(api.o): unrecognized relocation (0x2a) in section `.text._ZN2v89ExtensionD2Ev[_ZN2v89ExtensionD5Ev]'

Add Linux ARM targets

Possible on GHA via qemu and/or xbuild. Also available on Travis.

Considered targets:

aarch64
armv7
armv8

Update readme with publishing new release steps

          > What are the next steps we need here to publish a new version?

@SamSaffron since mini_racer version constraint on libv8-node is ~> 16.10.0.0 and this is clearly a bug fix, there is nothing to be done for node-16 on the mini_racer side, only pushing the new node 16 gems.

The typical libv8-node release process (that I should document) is:

merge whatever PRs are wanted for a release into node-X (here node-16)
wait for last merge commit CI to be green
do a Release X.Y.Z.W commit on the branch (like so). It should update changelogs and whatever too.
wait for CI to be green (it should given the changeset, but sometimes silly mistakes happen!)
tag that release commit vX.Y.Z.W
create a release from the tag on the GH page, and attach the CI artifacts of the release commit
push the CI artifact gems to rubygems

(Most of these can be automated via GH workflows, e.g tag => create GH release + attack artifacts + push to rubygems†. or it can be a manual GH "dispatch workflow")

† this one can also both require and wait for 2FA with some interesting techniques

The degraded libv8-node release process is the same, except (when CI is broken because reasons outside of release blockers):

merge whatever PRs are wanted for a release into node-X (here node-16)
wait for last merge commit CI to be as green as possible
do a Release X.Y.Z.W commit on the branch (like so). It should update changelogs and whatever too.
build x86_64-{darwin,linux,linux-musl} gems on an Intel machine (resp. make test, make test/linux, make test/linux-musl)
build arm64-darwin and aarch64-{linux,linux-musl}gems on an Intel machine (resp.make test, make test/linux, make test/linux-musl`)
build ruby platform gem with rake build
tag that release commit vX.Y.Z.W
create a release from the tag on the GH page, and attach the artifacts of the release commit
push the artifact gems to rubygems

Originally posted by @lloeki in #37 (comment)

libv8-node-15.14.0.0 does not build on Ruby 3.0.1 aarch64-linux

I was trying to use mini_racer 0.40.0 on Docker for Mac on an M1 machine, but libv8-node does not compile:

docker run -it --rm ruby:3.0.1 gem install libv8-node

See https://gist.github.com/tisba/6191aca022e288e102cb5db1a55d7377 for full output. Happy to provide more info if it helps.

Error relocating mini_racer_extension.so: backtrace_symbols: symbol not found on 2.5-alpine and 2.6-alpine

see e.g here

/home/runner/work/ruby-libv8-node/ruby-libv8-node/test/mini_racer/lib/mini_racer.rb:11:in `load': Error relocating /home/runner/work/ruby-libv8-node/ruby-libv8-node/test/mini_racer/lib/mini_racer_extension.so: backtrace_symbols: symbol not found (LoadError)
152
	from /home/runner/work/ruby-libv8-node/ruby-libv8-node/test/mini_racer/lib/mini_racer.rb:11:in `<top (required)>'

I'd like to write some documentation for the NJOBS feature in libexec/build-libv8

Usually when I find a useful feature in the code I like to surface this to the documentation.

Specifically this:

https://github.com/rubyjs/libv8-node/blob/master/libexec/build-libv8#L11-L12

I'm happy to write the docs, where should I put them?

README.md doesn't seem to include much about the "guts".... but I'm happy to put it there.

I wonder what the document structure should be. A proposal:

Technical Details

Build Issues

Improving Built Times Using Parallel Compile Jobs

That's just an example.....

Refactor test compilation code into correct script location

          > I'm trying to figure out where to put the ctest build and run commands, and it looks like maybe the libexec script files, but they are kind of mixed?

Hmm, good question. I don't think this should be published in the gem, so I would refrain from having it in libexec. I think a couple of shell files inside of test would be OK for now, to be called by some Makefile targets and GH workflow steps (but not ext/libv8-node/builder.rb)

(excluding the latter because e.g I don't want people to need cmake when installing from source)

Originally posted by @lloeki in #37 (comment)

Workflows do not use any artifacts in their later steps

https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts

Dev cycle times and workflow completion time would benefit from reusing built v8 binaries between workflow steps.

discovered during #37

Failure on install - make: printf: Argument list too long

Ruby 3.0.1p64
bundler 2.2.15

I previously installed 16.10.0.0 with no issue. Trying to bundle update rails makes it want to reinstall libv8-node for whatever reason. It runs for a few minutes then spits out a failure message that ends with:

/home/jason/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/libv8-node-16.10.0.0/src/node-v16.10.0/out/Release/obj.target/v8_base_without_compiler/deps/v8/src/api/api-arguments.o
../deps/v8/src/api/api-arguments.cc '-D_GLIBCXX_USE_CXX11_ABI=1' '-DV8_GYP_BUILD' '-DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64'
'-D__STDC_FORMAT_MACROS' '-DOPENSSL_THREADS' '-DOPENSSL_NO_ASM' '-DV8_TARGET_ARCH_X64' '-DV8_HAVE_TARGET_OS'
'-DV8_TARGET_OS_LINUX' '-DV8_EMBEDDER_STRING="-node.14"' '-DENABLE_DISASSEMBLER' '-DV8_PROMISE_INTERNAL_FIELD_COUNT=1'
'-DENABLE_MINOR_MC' '-DOBJECT_PRINT' '-DV8_INTL_SUPPORT' '-DV8_ENABLE_LAZY_SOURCE_POSITIONS' '-DV8_USE_SIPHASH'
'-DDISABLE_UNTRUSTED_CODE_MITIGATIONS' '-DV8_WIN64_UNWINDING_INFO' '-DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH'
'-DV8_SNAPSHOT_COMPRESSION' '-DV8_ENABLE_WEBASSEMBLY' '-DV8_ALLOCATION_FOLDING' '-DV8_ALLOCATION_SITE_TRACKING'
'-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC' '-DV8_ADVANCED_BIGINT_ALGORITHMS' '-DUCONFIG_NO_SERVICE=1' '-DU_ENABLE_DYLOAD=0'
'-DU_STATIC_IMPLEMENTATION=1' '-DU_HAVE_STD_STRING=1' '-DUCONFIG_NO_BREAK_ITERATION=0' -I../deps/v8 -I../deps/v8/include
-I/home/jason/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/libv8-node-16.10.0.0/src/node-v16.10.0/out/Release/obj/gen/inspector-generated-output-root
-I../deps/v8/third_party/inspector_protocol
-I/home/jason/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/libv8-node-16.10.0.0/src/node-v16.10.0/out/Release/obj/gen
-I/home/jason/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/libv8-node-16.10.0.0/src/node-v16.10.0/out/Release/obj/gen/generate-bytecode-output-root
-I../deps/icu-small/source/i18n -I../deps/icu-small/source/common -I../deps/v8/third_party/zlib
-I../deps/v8/third_party/zlib/google  -pthread -Wno-unused-parameter -m64 -fPIC -Wno-return-type -fno-strict-aliasing -m64 -O3
-fno-omit-frame-pointer -fdata-sections -ffunction-sections -O3 -fno-rtti -fno-exceptions -std=gnu++14 -MMD -MF
/home/jason/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/libv8-node-16.10.0.0/src/node-v16.10.0/out/Release/.deps//home/jason/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/libv8-node-16.10.0.0/src/node-v16.10.0/out/Release/obj.target/v8_base_without_compiler/deps/v8/src/api/api-arguments.o.d.raw
-c
touch
/home/jason/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/libv8-node-16.10.0.0/src/node-v16.10.0/out/Release/obj.target/tools/v8_gypfiles/v8_compiler_for_mksnapshot.stamp
make: printf: Argument list too long
make: *** [tools/v8_gypfiles/v8_base_without_compiler.target.mk:1024:
/home/jason/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/libv8-node-16.10.0.0/src/node-v16.10.0/out/Release/obj.target/tools/v8_gypfiles/libv8_base_without_compiler.a]
Error 127
rm e0727ef2578d31016f6519be3cc91e6a8866de8e.intermediate 9ca6cd0d4c4bcbf36d91131f11c8e7f75c82228e.intermediate
make: Leaving directory '/home/jason/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/libv8-node-16.10.0.0/src/node-v16.10.0/out'
/home/jason/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/libv8-node-16.10.0.0/ext/libv8-node/builder.rb:14:in `build_libv8!':
failed to build libv8 16.10.0 (Libv8::Node::BuilderError)
	from /home/jason/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/libv8-node-16.10.0.0/ext/libv8-node/location.rb:30:in `install!'
	from extconf.rb:9:in `<main>'

extconf failed, exit code 1

Gem files will remain installed in /home/jason/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/libv8-node-16.10.0.0 for inspection.
Results logged to
/home/jason/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/extensions/x86_64-linux/3.0.0/libv8-node-16.10.0.0/gem_make.out

An error occurred while installing libv8-node (16.10.0.0), and Bundler cannot continue.
Make sure that `gem install libv8-node -v '16.10.0.0' --source 'https://rubygems.org/'` succeeds before bundling.

In Gemfile:
  mini_racer was resolved to 0.5.0, which depends on
    libv8-node

Create building and contributing md files.

          >> See BUILDING.md. Also make sure to read CONTRIBUTING.md if you plan to help.

These files don't seem to exist-- did they move or something? I feel like we should throw a few things in here for our future selves.

Hmm, not sure. Maybe I forgot to add these. Feel free to fill some stuff in if you're keen on it!

A separate PR from this one would be good.

Originally posted by @lloeki in #37 (comment)

Publishing binary for new macOS versions

It seems like the latest x86 macOS is x86_64-darwin22. I have one of these would like to see if I can help with publishing the binary. How can I go about this?
Does it need to via Github actions?

`libv8-node-15.14.0.1-x86_64-linux.gem` does not match the checksum given by the server.

No idea what's going on, but this fails on GitHub Actions

Bundler cannot continue installing libv8-node (15.14.0.1).
The checksum for the downloaded `libv8-node-15.14.0.1-x86_64-linux.gem` does not
match the checksum given by the server. This means the contents of the
downloaded gem is different from what was uploaded to the server, and could be a
potential security issue.

Context: https://github.com/casperisfine/execjs/runs/2525552109

Performance is bad when running mini_racer tests

Doesn't seem to affect Linux (glibc at least). Has happened on musl at least once.

Example on macOS (libv8-node):

Fabulous run in 90.207620s, 0.9201 runs/s, 1.5409 assertions/s.

vs (libv8)

Fabulous run in 2.528212s, 32.8295 runs/s, 54.9796 assertions/s.

Change default branch to `main`

Update to the current github standard.

Add cross-compiled aarch64-linux-musl build

Investigate V8_ASSUME_ALIGNED warning on macOS

Has no apparent functional effect on result: mini_racer tests still pass with about the same performance.

Started when building the newly added gyp target libv8_monolith instead of node.

In file included from ../deps/v8/src/compiler/compilation-dependencies.cc:10:
2272
In file included from ../deps/v8/src/objects/allocation-site-inl.h:10:
2273
In file included from ../deps/v8/src/heap/heap-write-barrier-inl.h:15:
2274
In file included from ../deps/v8/src/objects/compressed-slots-inl.h:10:
2275
../deps/v8/src/common/ptr-compr-inl.h:43:44: warning: requested alignment must be 536870912 bytes or smaller; maximum alignment assumed [-Wbuiltin-assume-aligned-alignment]
2276
  isolate_root = reinterpret_cast<Address>(V8_ASSUME_ALIGNED(
2277
                                           ^~~~~~~~~~~~~~~~~~
2278
../deps/v8/include/v8config.h:364:3: note: expanded from macro 'V8_ASSUME_ALIGNED'
2279
  __builtin_assume_aligned((ptr), (alignment))
2280
  ^                               ~~~~~~~~~~~

Shorten build time by building only v8

It is not needed to build the whole of Node, as only v8 is needed.

Some notes:

./configure
# records python2.7 vs python3.x, but fails to detect literal `python3`

make
# calls out make -C out BUILDTYPE=Release V=0
# also sources config.mk

According to BUILD.gn, libv8_monolith.a has v8, v8_libbase, v8_libsampler, v8_libpolatform as dependencies, so the following might be sufficient, although it doesn't source config.mk for the -C out ones.

[python2|python3] configure.py --openssl-no-asm --without-npm
make BUILDTYPE=Release out/Makefile
make -C out BUILDTYPE=Release V=0 v8
make -C out BUILDTYPE=Release V=0 v8_libbase
make -C out BUILDTYPE=Release V=0 v8_libplatform
make -C out BUILDTYPE=Release V=0 v8_libsampler

error running rake binary:all

I get this error when running the command

TypeError: no implicit conversion of nil into String
/Users/andrewjones/Documents/projects/aha/ruby-libv8-node/Rakefile:63:in `read'

Am I missing some step to have contents at src/node-v...

@lloeki Would very much appreciate guidance on how to get this workflow running - I am testing out the capability of publishing a forked version of this gem with node v16 v8 - thanks!

Published build for 16.10.0.0-x86_64-darwin-20

Hello,

I have been having issues on my machine trying to use the latest mini_racer (0.6.2) which depends on the latest libv8-node. I am able to use an older version of mini_racer which uses libv8-node 15.14.0.1, and on my machine, a build specifically for darwin-20.

*** LOCAL GEMS ***

libv8-node (16.10.0.0 ruby x86_64-darwin, 15.14.0.1 x86_64-darwin-20)

I'm thinking if you were to publish a darwin-20 specific gem it may address the problems I am experiencing. Thanks!

Please cut a release with latest LTS v16.14.2

Move from -darwinXY to -darwin (no version)

Add s390x target

libv8-node 17.3.1 doesn't build because of Python 3.10, 3.9

The gem doesn't build, despite having the Python versions it asks for (3.10, 3.9, as well as 2.7).

==== running /usr/share/rvm/gems/ruby-3.2.0/gems/libv8-node-17.3.1.0/libexec/build-libv8
parallel job count: 4
configure: --openssl-no-asm --without-npm --shared --with-intl=full-icu
compilers: CC='gcc' CXX='g++' CC_host='' CXX_host=''
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/11/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/11/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
Please use python3.10 or python3.9 or python3.8 or python3.7 or python3.6.
        /usr/bin/python3.9 configure
Node.js configure: Found Python 2.7.18...
/usr/share/rvm/gems/ruby-3.2.0/gems/libv8-node-17.3.1.0/ext/libv8-node/builder.rb:14:in `build_libv8!': failed to build libv8 17.3.1 (Libv8::Node::BuilderError)
        from /usr/share/rvm/gems/ruby-3.2.0/gems/libv8-node-17.3.1.0/ext/libv8-node/location.rb:30:in `install!'
        from extconf.rb:9:in `<main>'

extconf failed, exit code 1

Built v8 is not being used in ruby platform tests.

Something I just noticed about the ruby platform tests: They don't seem to use the ruby platform gem at all.
It's compiled and installed alright, but the actual "Test with mini_racer" step then turns around and downloads libv8-node with the "correct" arch + libc from https://rubygems.org/

Originally posted by @Fayti1703 in #37 (comment)