build: fix Windows small-icu build with ClangCL - #64263
Conversation
Signed-off-by: moluopro <[email protected]>
|
Review requested:
|
StefanStojanovic
left a comment
There was a problem hiding this comment.
Tested it locally and it worked.
|
This needs a rebase, and resolving conflicts in |
|
Thanks, but could you clarify why #65095, which was opened later to address the same issue, was merged before this already-approved PR? |
I looked into #65095. It's possible that collaborators prioritized it's review since a bug report was linked to it? |
|
Closing since it's fixed in #65095 |
Both routes advanced and each hit one thing. conda-clang-cl (ninja) compiled 500 edges with clang-cl 21.1.8 -- ICU, the host tools, the builtins library found and on the link line -- and stopped in v8_libbase at v8config.h: "C++20 or later required." Two causes, both needed fixing: - gyp's ninja generator appends CFLAGS, CXXFLAGS and LDFLAGS from the environment after its own flags, and conda's clang-cl activation exports /std:c++17 in CXXFLAGS, which then outranked whatever V8 said. bld.bat now strips /std:, -std and -fuse-ld= from those, and clears LDFLAGS: the `-Xlinker /DEFAULTLIB:...` there is clang-driver syntax that link.exe answered with LNK4044, and patch 0104 already links the builtins library in a form it understands. build.sh strips -std= for the same reason. - Even with a clean environment there was no /std: at all: with clang, common.gypi expresses the standard as the MSBuild-only property LanguageStandard (stdcpp20), and gyp's ninja emulation has no case for it. Patch 0106 adds one, per language -- C files get /std:c11, not c++20, which clang-cl would refuse where cl.exe ignores it. Verified on Windows ninja files generated here (gyp's ninja-win flavour, with its registry probes stubbed): cflags_cc = /TP /std:c++20, cflags_c = /std:c11, and the MSVC branch's -std:c++20 gone. vs-clang-cl (MSBuild) built ICU's tools with Visual Studio's clang-cl 22.1.3 and stopped writing the ICU data object: genccode: CPU architecture must be set for Clang-CL A genccode compiled by clang will not infer the machine type from its own macros, and node's small-icu action for Windows never passed -c. Node's Windows builds are full-icu, so nobody hit it until now; the fix is nodejs/node#64263, after 26.6.0, and patch 0107 is that one line. The ninja route runs the same action and would have reached it too. Also caught before it could fail: v8config.h guards on __cplusplus, which cl.exe reports as 199711L unless given /Zc:__cplusplus. The consumer test compiles with cl.exe on Windows, so it gets the flag. Co-Authored-By: Claude Fable 5.1 <[email protected]> Claude-Session: https://claude.ai/code/session_01KzqRnuUy9dpMik6sxVaKXd
When building the static
libnodelibrary withsmall-icuon Windows, thegenccodestep fails under ClangCL because the target CPU architecture is not passed to the tool.The Windows full-ICU branch already passes
-c <(target_arch)togenccodewhenclang==1, while preserving the existing MSVC command. The small-ICU branch did not have the same conditional handling, so it hit ICU's architecture check under ClangCL.This change makes the Windows small-ICU branch consistent with the full-ICU branch:
-c <(target_arch)whenclang==1.genccodecommand unchanged for the non-ClangCL MSVC path.Reproduction
Windows builds for Node.js 24+ use ClangCL, and the build fails with: