core/core-agent-ide
8
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
core-agent-ide/third_party/v8
History
Exact
Channing Conger 1350477150
Add v8-poc consumer of our new built v8 (#15203) 
This adds a dummy v8-poc project that in Cargo links against our
prebuilt binaries and the ones provided by rusty_v8 for non musl
platforms. This demonstrates that we can successfully link and use v8 on
all platforms that we want to target.

In bazel things are slightly more complicated. Since the libraries as
published have libc++ linked in already we end up with a lot of double
linked symbols if we try to use them in bazel land. Instead we fall back
to building rusty_v8 and v8 from source (cached of course) on the
platforms we ship to.

There is likely some compatibility drift in the windows bazel builder
that we'll need to reconcile before we can re-enable them. I'm happy to
be on the hook to unwind that.
2026-03-20 12:08:25 -07:00
..
BUILD.bazel Add v8-poc consumer of our new built v8 (#15203) 2026-03-20 12:08:25 -07:00
README.md Add v8-poc consumer of our new built v8 (#15203) 2026-03-20 12:08:25 -07:00
v8_crate.BUILD.bazel V8 Bazel Build (#15021) 2026-03-19 18:05:23 -07:00

README.md

rusty_v8 Consumer Artifacts

This directory wires the v8 crate to exact-version Bazel inputs. Bazel consumer builds use:

  • upstream denoland/rusty_v8 release archives on Windows
  • source-built V8 archives on Darwin, GNU Linux, and musl Linux
  • openai/codex release assets for published musl release pairs

Cargo builds still use prebuilt rusty_v8 archives by default. Only Bazel overrides RUSTY_V8_ARCHIVE/RUSTY_V8_SRC_BINDING_PATH in MODULE.bazel to select source-built local archives for its consumer builds.

Current pinned versions:

  • Rust crate: v8 = =146.4.0
  • Embedded upstream V8 source for musl release builds: 14.6.202.9

The consumer-facing selectors are:

  • //third_party/v8:rusty_v8_archive_for_target
  • //third_party/v8:rusty_v8_binding_for_target

Musl release assets are expected at the tag:

  • rusty-v8-v<crate_version>

with these raw asset names:

  • librusty_v8_release_<target>.a.gz
  • src_binding_release_<target>.rs

The dedicated publishing workflow is .github/workflows/rusty-v8-release.yml. It builds musl release pairs from source and keeps the release artifacts as the statically linked form:

  • //third_party/v8:rusty_v8_release_pair_x86_64_unknown_linux_musl
  • //third_party/v8:rusty_v8_release_pair_aarch64_unknown_linux_musl

Cargo musl builds use RUSTY_V8_ARCHIVE plus a downloaded RUSTY_V8_SRC_BINDING_PATH to point at those openai/codex release assets directly. We do not use RUSTY_V8_MIRROR for musl because the upstream v8 crate hardcodes a v<crate_version> tag layout, while our musl artifacts are published under rusty-v8-v<crate_version>.

Do not mix artifacts across crate versions. The archive and binding must match the exact resolved v8 crate version in codex-rs/Cargo.lock.