Skip to content

build: fix static_lib_name for non-MSVC Windows toolchains#1957

Open
ognevny wants to merge 1 commit into
denoland:mainfrom
ognevny:patch-1
Open

build: fix static_lib_name for non-MSVC Windows toolchains#1957
ognevny wants to merge 1 commit into
denoland:mainfrom
ognevny:patch-1

Conversation

@ognevny

@ognevny ognevny commented Apr 13, 2026

Copy link
Copy Markdown

only MSVC uses such library names, other toolchains (like MinGW) apply lib prefix and use .a extension for static libraries

only MSVC uses such library names, other toolchains (like MinGW) apply lib prefix and use .a extension for static libraries
@bartlomieju

Copy link
Copy Markdown
Member

Thanks for the PR, but I'm wary to fix something that is working correctly without associated test or rationale. Can you provide more context on this change?

@ognevny

ognevny commented Apr 22, 2026

Copy link
Copy Markdown
Author

when we use GCC or Clang even on Windows, they use Linux-like way to name libraries. that includes lib prefix and .a extension for static libraries. also Rust's definition of windows-gnu and windows-gnullvm follow this

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