Skip to content

fix: use real GN arg for linux shared-library TLS mode#1970

Open
crowlKats wants to merge 1 commit into
mainfrom
fix/shared-library-tls-arg
Open

fix: use real GN arg for linux shared-library TLS mode#1970
crowlKats wants to merge 1 commit into
mainfrom
fix/shared-library-tls-arg

Conversation

@crowlKats
Copy link
Copy Markdown
Member

Summary

Fixes the shared-library TLS mode injection introduced in #1911 -- the previous implementation wrote extra_cflags=["-DV8_TLS_USED_IN_LIBRARY"] into args.gn, but extra_cflags is not a declared top-level GN arg anywhere in chromium_build or V8. It's only used as an invoker parameter inside toolchain definitions (build/toolchain/gcc_toolchain.gni:277). GN silently accepts unknown args, so the define never reached the compiler. V8's thread-locals stayed in local-exec TLS model, and linking rusty_v8 into a downstream cdylib failed with:

rust-lld: error: relocation R_X86_64_TPOFF32 against
  v8::internal::g_current_isolate_ cannot be used with -shared

You can verify on main today: build with V8_FROM_SOURCE=1, then grep gn_out/obj/v8/v8_base_without_compiler.ninja -- V8_TLS_USED_IN_LIBRARY is absent from the defines = ... line, despite being present in args.gn.

Change

Replace the extra_cflags=[...] injection with v8_monolithic_for_shared_library=true, which is a real declared GN arg in V8's BUILD.gn:379.

Companion change in denoland/v8

This PR alone is not sufficient -- denoland/v8#20 is required to wire v8_monolithic_for_shared_library into V8's internal_config so the define actually reaches V8 internal .cc files (where the TLS variables live). Currently the arg only adds the define inside the :features config, which is consumed only by external embedders, not by V8 itself.

This rusty_v8 PR should land after denoland/v8#20 has been picked up by the autoroll into 14.7-lkgr-denoland and the v8 submodule pointer here has been bumped to that commit.

Test plan

  • After v8 PR lands and submodule is bumped: V8_FROM_SOURCE=1 cargo build succeeds for a cdylib downstream (verified locally against Deno's denort_desktop).
  • Grep generated gn_out/obj/v8/v8_base_without_compiler.ninja -- V8_TLS_USED_IN_LIBRARY is now in defines = ....

#1911 tried to inject `V8_TLS_USED_IN_LIBRARY` into V8's compilation by
writing `extra_cflags=["-DV8_TLS_USED_IN_LIBRARY"]` into args.gn, but
`extra_cflags` isn't a declared top-level GN arg anywhere in
chromium_build or V8 -- it's only used as an *invoker parameter* inside
toolchain definitions in `build/toolchain/gcc_toolchain.gni`. GN
silently accepts unknown args, so the define never reached the
compiler. V8's thread-locals stayed in `local-exec` TLS model, and
linking rusty_v8 into a downstream cdylib failed with:

  rust-lld: error: relocation R_X86_64_TPOFF32 against
    v8::internal::g_current_isolate_ cannot be used with -shared

You can verify by grepping the generated
`gn_out/obj/v8/v8_base_without_compiler.ninja` after a build --
`V8_TLS_USED_IN_LIBRARY` is absent from `defines = ...`.

Switch to setting `v8_monolithic_for_shared_library=true`, which is a
real declared GN arg in V8's BUILD.gn. The companion denoland/v8 patch
(#TBD) wires that arg into `internal_config` so the define actually
reaches V8 internal `.cc` files where the TLS variables live.
@mdesantis
Copy link
Copy Markdown

mdesantis commented Apr 26, 2026

👋 We ran into this issue while trying to link rusty_v8 into a Ruby native extension (cdylib) via V8_FROM_SOURCE=1. Confirmed that the extra_cflags approach in #1911 does not work — V8_TLS_USED_IN_LIBRARY never reaches the compiler. Looking forward to this fix landing!

@mdesantis
Copy link
Copy Markdown

Hello! Is there any chance for this PR to be be merged soon? I have a library for Ruby similar to https://github.com/aglundahl/deno_rider I'd like to publish which depends on it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants