Skip to content

fix(build): link proper cxx std libraries on windows-gnu{,llvm} - #1880

Open
ognevny wants to merge 1 commit into
denoland:mainfrom
ognevny:windows-gnu-libs
Open

fix(build): link proper cxx std libraries on windows-gnu{,llvm}#1880
ognevny wants to merge 1 commit into
denoland:mainfrom
ognevny:windows-gnu-libs

Conversation

@ognevny

@ognevny ognevny commented Nov 19, 2025

Copy link
Copy Markdown

*-pc-windows-gnullvm targets use Clang toolchain, so the std library for it is libc++, pthread is needed to be explicitly linked too.

*-pc-windows-gnu build also depends on libatomic

@CLAassistant

CLAassistant commented Nov 19, 2025

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

`*-pc-windows-gnullvm` targets use Clang toolchain, so the std library for it is libc++, pthread is needed to be explicitly linked too.

`*-pc-windows-gnu` build also depends on `libatomic`
jayvdb added a commit to jayvdb/rusty_v8 that referenced this pull request Jul 7, 2026
Build rusty_v8 for the windows-gnullvm target with the OSS llvm-mingw
toolchain (clang + lld + mingw-w64 UCRT + libc++), producing a
librusty_v8.a prebuilt that GNU-toolchain Windows consumers can link.

gnullvm/apply-patches.sh applies the MSYS2 mingw-w64-v8 porting patches
(vendored in the previous commit; 001/002/004/014 rebased here onto
denoland's chromium_build/V8 forks, plus new 018-020) to the vendored
sub-repos before a from-source build:
- 001 (chromium_build): mingw toolchain definition; compiler/linker
  configs; define visual_studio_runtime_dirs ("" not []) and skip the
  MSVC setup_toolchain.py in win_toolchain_data so gn gen works without
  Visual Studio; guard clang-cl/Chromium-clang-only flags, /NATVIS and
  MSVC debug-info ldflags with is_msvc/is_mingw; link winpthreads in
  default_libs; bare lib names (no .lib) for mingw.
- 002-014, 017 (v8): source portability fixes for clang-in-mingw mode,
  incl. SEH unwind info for PushAllRegistersAndIterateStack (llvm-mingw
  cannot assemble the masm version the upstream #error points to).
- 018 (icu), 019 (tools/win natvis), 020 (abseil bcrypt): MSVC-only
  cflags/ldflags/lib-name fixes.

build.rs: builds on ognevny's denoland#1957 (librusty_v8.a naming for non-MSVC)
and denoland#1880 (libc++/libatomic/pthread link flags), extending the gnullvm
arm to also link the Win32 import libs V8/abseil reference via
/DEFAULTLIB pragmas (ld.lld in mingw mode ignores those directives);
bindgen --target=x86_64-w64-windows-gnu + llvm-mingw resource dir
(libclang rejects the gnullvm triple).

BUILD.gn: the /Zl binding cflag is MSVC-only (is_msvc, not is_win).

CI: build-windows-gnullvm job builds the simdutf prebuilt (deno_core
always enables that feature) from source with the latest llvm-mingw,
stages the llvm-mingw runtime DLLs next to the test exes, and publishes
librusty_v8_simdutf_release_x86_64-pc-windows-gnullvm.a.gz +
src_binding. 13 tests are skipped: a Rust panic cannot unwind across V8
C++ frames on gnullvm (0xc0000409 "failed to initiate panic") -- tracked
separately. Expensive non-Windows jobs are gated off on this dev branch.

Verified locally on Windows 11 with llvm-mingw 20260602 and on GHA with
20260616: all patches apply to the pinned v150 submodules, the full
from-source build succeeds (mksnapshot runs), and nextest passes 284
tests with the 13 known panic-unwind skips.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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