build: fix Windows small-icu build with ClangCL by moluopro · Pull Request #64263 · nodejs/node

moluopro · 2026-07-02T16:14:42Z

When building the static libnode library with small-icu on Windows, the genccode step fails under ClangCL because the target CPU architecture is not passed to the tool.

The Windows full-ICU branch already passes -c <(target_arch) to genccode when clang==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:

Pass -c <(target_arch) when clang==1.
Keep the existing genccode command unchanged for the non-ClangCL MSVC path.

Reproduction

$env:config_flags='--v8-disable-temporal-support'
.\vcbuild.batstatic nonpm small-icu no-cctest openssl-no-asm x64

Windows builds for Node.js 24+ use ClangCL, and the build fails with:

genccode
genccode: CPU architecture must be set for Clang-CL
Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for '..\..\deps\icu-tmp\icudt78l.dat;..\..\out\Release\\obj\global_intermediate\icutmp\icudt78l.dat' exited with code 1. [...\tools\icu\icudata.vcxproj]

Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot · 2026-07-02T16:14:47Z

Review requested:

@nodejs/gyp

StefanStojanovic

Tested it locally and it worked.

nodejs-github-bot · 2026-07-06T13:48:52Z

CI: https://ci.nodejs.org/job/node-test-pull-request/74595/

trivikr · 2026-08-21T00:36:26Z

This needs a rebase, and resolving conflicts in tools/icu/icu-generic.gyp

moluopro · 2026-08-21T03:27:28Z

Thanks, but could you clarify why #65095, which was opened later to address the same issue, was merged before this already-approved PR?

trivikr · 2026-08-22T23:02:29Z

#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?
There can be other reasons. I came across this PR while looking into approved PRs and posted what needs to be done to get this to merged.

trivikr · 2026-08-22T23:03:31Z

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 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KzqRnuUy9dpMik6sxVaKXd

moluopro · 2026-07-02T16:14:42Z

When building the static libnode library with small-icu on Windows, the genccode step fails under ClangCL because the target CPU architecture is not passed to the tool.

The Windows full-ICU branch already passes -c <(target_arch) to genccode when clang==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:

Pass -c <(target_arch) when clang==1.
Keep the existing genccode command unchanged for the non-ClangCL MSVC path.

Reproduction

$env:config_flags='--v8-disable-temporal-support'
.\vcbuild.batstatic nonpm small-icu no-cctest openssl-no-asm x64

Windows builds for Node.js 24+ use ClangCL, and the build fails with:

genccode
genccode: CPU architecture must be set for Clang-CL
Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for '..\..\deps\icu-tmp\icudt78l.dat;..\..\out\Release\\obj\global_intermediate\icutmp\icudt78l.dat' exited with code 1. [...\tools\icu\icudata.vcxproj]

Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot · 2026-07-02T16:14:47Z

Review requested:

@nodejs/gyp

StefanStojanovic

Tested it locally and it worked.

nodejs-github-bot · 2026-07-06T13:48:52Z

CI: https://ci.nodejs.org/job/node-test-pull-request/74595/

trivikr · 2026-08-21T00:36:26Z

This needs a rebase, and resolving conflicts in tools/icu/icu-generic.gyp

moluopro · 2026-08-21T03:27:28Z

Thanks, but could you clarify why #65095, which was opened later to address the same issue, was merged before this already-approved PR?

trivikr · 2026-08-22T23:02:29Z

#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?
There can be other reasons. I came across this PR while looking into approved PRs and posted what needs to be done to get this to merged.

trivikr · 2026-08-22T23:03:31Z

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 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KzqRnuUy9dpMik6sxVaKXd

moluopro · 2026-07-02T16:14:42Z

When building the static libnode library with small-icu on Windows, the genccode step fails under ClangCL because the target CPU architecture is not passed to the tool.

The Windows full-ICU branch already passes -c <(target_arch) to genccode when clang==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:

Pass -c <(target_arch) when clang==1.
Keep the existing genccode command unchanged for the non-ClangCL MSVC path.

Reproduction

$env:config_flags='--v8-disable-temporal-support'
.\vcbuild.batstatic nonpm small-icu no-cctest openssl-no-asm x64

Windows builds for Node.js 24+ use ClangCL, and the build fails with:

genccode
genccode: CPU architecture must be set for Clang-CL
Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for '..\..\deps\icu-tmp\icudt78l.dat;..\..\out\Release\\obj\global_intermediate\icutmp\icudt78l.dat' exited with code 1. [...\tools\icu\icudata.vcxproj]

Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot · 2026-07-02T16:14:47Z

Review requested:

@nodejs/gyp

StefanStojanovic

Tested it locally and it worked.

nodejs-github-bot · 2026-07-06T13:48:52Z

CI: https://ci.nodejs.org/job/node-test-pull-request/74595/

trivikr · 2026-08-21T00:36:26Z

This needs a rebase, and resolving conflicts in tools/icu/icu-generic.gyp

moluopro · 2026-08-21T03:27:28Z

Thanks, but could you clarify why #65095, which was opened later to address the same issue, was merged before this already-approved PR?

trivikr · 2026-08-22T23:02:29Z

#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?
There can be other reasons. I came across this PR while looking into approved PRs and posted what needs to be done to get this to merged.

trivikr · 2026-08-22T23:03:31Z

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 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KzqRnuUy9dpMik6sxVaKXd

moluopro · 2026-07-02T16:14:42Z

When building the static libnode library with small-icu on Windows, the genccode step fails under ClangCL because the target CPU architecture is not passed to the tool.

The Windows full-ICU branch already passes -c <(target_arch) to genccode when clang==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:

Pass -c <(target_arch) when clang==1.
Keep the existing genccode command unchanged for the non-ClangCL MSVC path.

Reproduction

$env:config_flags='--v8-disable-temporal-support'
.\vcbuild.batstatic nonpm small-icu no-cctest openssl-no-asm x64

Windows builds for Node.js 24+ use ClangCL, and the build fails with:

genccode
genccode: CPU architecture must be set for Clang-CL
Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for '..\..\deps\icu-tmp\icudt78l.dat;..\..\out\Release\\obj\global_intermediate\icutmp\icudt78l.dat' exited with code 1. [...\tools\icu\icudata.vcxproj]

Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot · 2026-07-02T16:14:47Z

Review requested:

@nodejs/gyp

StefanStojanovic

Tested it locally and it worked.

nodejs-github-bot · 2026-07-06T13:48:52Z

CI: https://ci.nodejs.org/job/node-test-pull-request/74595/

trivikr · 2026-08-21T00:36:26Z

This needs a rebase, and resolving conflicts in tools/icu/icu-generic.gyp

moluopro · 2026-08-21T03:27:28Z

Thanks, but could you clarify why #65095, which was opened later to address the same issue, was merged before this already-approved PR?

trivikr · 2026-08-22T23:02:29Z

#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?
There can be other reasons. I came across this PR while looking into approved PRs and posted what needs to be done to get this to merged.

trivikr · 2026-08-22T23:03:31Z

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 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KzqRnuUy9dpMik6sxVaKXd

moluopro · 2026-07-02T16:14:42Z

When building the static libnode library with small-icu on Windows, the genccode step fails under ClangCL because the target CPU architecture is not passed to the tool.

The Windows full-ICU branch already passes -c <(target_arch) to genccode when clang==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:

Pass -c <(target_arch) when clang==1.
Keep the existing genccode command unchanged for the non-ClangCL MSVC path.

Reproduction

$env:config_flags='--v8-disable-temporal-support'
.\vcbuild.batstatic nonpm small-icu no-cctest openssl-no-asm x64

Windows builds for Node.js 24+ use ClangCL, and the build fails with:

genccode
genccode: CPU architecture must be set for Clang-CL
Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for '..\..\deps\icu-tmp\icudt78l.dat;..\..\out\Release\\obj\global_intermediate\icutmp\icudt78l.dat' exited with code 1. [...\tools\icu\icudata.vcxproj]

Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot · 2026-07-02T16:14:47Z

Review requested:

@nodejs/gyp

StefanStojanovic

Tested it locally and it worked.

nodejs-github-bot · 2026-07-06T13:48:52Z

CI: https://ci.nodejs.org/job/node-test-pull-request/74595/

trivikr · 2026-08-21T00:36:26Z

This needs a rebase, and resolving conflicts in tools/icu/icu-generic.gyp

moluopro · 2026-08-21T03:27:28Z

Thanks, but could you clarify why #65095, which was opened later to address the same issue, was merged before this already-approved PR?

trivikr · 2026-08-22T23:02:29Z

#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?
There can be other reasons. I came across this PR while looking into approved PRs and posted what needs to be done to get this to merged.

trivikr · 2026-08-22T23:03:31Z

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 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KzqRnuUy9dpMik6sxVaKXd

moluopro · 2026-07-02T16:14:42Z

When building the static libnode library with small-icu on Windows, the genccode step fails under ClangCL because the target CPU architecture is not passed to the tool.

The Windows full-ICU branch already passes -c <(target_arch) to genccode when clang==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:

Pass -c <(target_arch) when clang==1.
Keep the existing genccode command unchanged for the non-ClangCL MSVC path.

Reproduction

$env:config_flags='--v8-disable-temporal-support'
.\vcbuild.batstatic nonpm small-icu no-cctest openssl-no-asm x64

Windows builds for Node.js 24+ use ClangCL, and the build fails with:

genccode
genccode: CPU architecture must be set for Clang-CL
Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for '..\..\deps\icu-tmp\icudt78l.dat;..\..\out\Release\\obj\global_intermediate\icutmp\icudt78l.dat' exited with code 1. [...\tools\icu\icudata.vcxproj]

Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot · 2026-07-02T16:14:47Z

Review requested:

@nodejs/gyp

StefanStojanovic

Tested it locally and it worked.

nodejs-github-bot · 2026-07-06T13:48:52Z

CI: https://ci.nodejs.org/job/node-test-pull-request/74595/

trivikr · 2026-08-21T00:36:26Z

This needs a rebase, and resolving conflicts in tools/icu/icu-generic.gyp

moluopro · 2026-08-21T03:27:28Z

Thanks, but could you clarify why #65095, which was opened later to address the same issue, was merged before this already-approved PR?

trivikr · 2026-08-22T23:02:29Z

#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?
There can be other reasons. I came across this PR while looking into approved PRs and posted what needs to be done to get this to merged.

trivikr · 2026-08-22T23:03:31Z

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 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KzqRnuUy9dpMik6sxVaKXd

moluopro · 2026-07-02T16:14:42Z

When building the static libnode library with small-icu on Windows, the genccode step fails under ClangCL because the target CPU architecture is not passed to the tool.

The Windows full-ICU branch already passes -c <(target_arch) to genccode when clang==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:

Pass -c <(target_arch) when clang==1.
Keep the existing genccode command unchanged for the non-ClangCL MSVC path.

Reproduction

$env:config_flags='--v8-disable-temporal-support'
.\vcbuild.batstatic nonpm small-icu no-cctest openssl-no-asm x64

Windows builds for Node.js 24+ use ClangCL, and the build fails with:

genccode
genccode: CPU architecture must be set for Clang-CL
Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for '..\..\deps\icu-tmp\icudt78l.dat;..\..\out\Release\\obj\global_intermediate\icutmp\icudt78l.dat' exited with code 1. [...\tools\icu\icudata.vcxproj]

Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot · 2026-07-02T16:14:47Z

Review requested:

@nodejs/gyp

StefanStojanovic

Tested it locally and it worked.

nodejs-github-bot · 2026-07-06T13:48:52Z

CI: https://ci.nodejs.org/job/node-test-pull-request/74595/

trivikr · 2026-08-21T00:36:26Z

This needs a rebase, and resolving conflicts in tools/icu/icu-generic.gyp

moluopro · 2026-08-21T03:27:28Z

Thanks, but could you clarify why #65095, which was opened later to address the same issue, was merged before this already-approved PR?

trivikr · 2026-08-22T23:02:29Z

#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?
There can be other reasons. I came across this PR while looking into approved PRs and posted what needs to be done to get this to merged.

trivikr · 2026-08-22T23:03:31Z

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 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KzqRnuUy9dpMik6sxVaKXd

moluopro · 2026-07-02T16:14:42Z

When building the static libnode library with small-icu on Windows, the genccode step fails under ClangCL because the target CPU architecture is not passed to the tool.

The Windows full-ICU branch already passes -c <(target_arch) to genccode when clang==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:

Pass -c <(target_arch) when clang==1.
Keep the existing genccode command unchanged for the non-ClangCL MSVC path.

Reproduction

$env:config_flags='--v8-disable-temporal-support'
.\vcbuild.batstatic nonpm small-icu no-cctest openssl-no-asm x64

Windows builds for Node.js 24+ use ClangCL, and the build fails with:

genccode
genccode: CPU architecture must be set for Clang-CL
Microsoft.CppCommon.targets(254,5): error MSB8066: Custom build for '..\..\deps\icu-tmp\icudt78l.dat;..\..\out\Release\\obj\global_intermediate\icutmp\icudt78l.dat' exited with code 1. [...\tools\icu\icudata.vcxproj]

Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot · 2026-07-02T16:14:47Z

Review requested:

@nodejs/gyp

StefanStojanovic

Tested it locally and it worked.

nodejs-github-bot · 2026-07-06T13:48:52Z

CI: https://ci.nodejs.org/job/node-test-pull-request/74595/

trivikr · 2026-08-21T00:36:26Z

This needs a rebase, and resolving conflicts in tools/icu/icu-generic.gyp

moluopro · 2026-08-21T03:27:28Z

Thanks, but could you clarify why #65095, which was opened later to address the same issue, was merged before this already-approved PR?

trivikr · 2026-08-22T23:02:29Z

#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?
There can be other reasons. I came across this PR while looking into approved PRs and posted what needs to be done to get this to merged.

trivikr · 2026-08-22T23:03:31Z

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 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KzqRnuUy9dpMik6sxVaKXd

build,win: fix small-icu build with ClangCL
63c4939
Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot added i18n-api Issues and PRs related to Node.js internationalization support. icu Issues and PRs related to the ICU dependency. needs-ci PRs that need a full CI run. tools Issues and PRs related to the tools directory. labels Jul 2, 2026

StefanStojanovic approved these changes Jul 3, 2026
View reviewed changes

richardlau added the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

github-actionsBot removed the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

trivikr closed this Aug 22, 2026

build,win: fix small-icu build with ClangCL
63c4939
Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot added i18n-api Issues and PRs related to Node.js internationalization support. icu Issues and PRs related to the ICU dependency. needs-ci PRs that need a full CI run. tools Issues and PRs related to the tools directory. labels Jul 2, 2026

StefanStojanovic approved these changes Jul 3, 2026
View reviewed changes

richardlau added the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

github-actionsBot removed the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

trivikr closed this Aug 22, 2026

build,win: fix small-icu build with ClangCL
63c4939
Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot added i18n-api Issues and PRs related to Node.js internationalization support. icu Issues and PRs related to the ICU dependency. needs-ci PRs that need a full CI run. tools Issues and PRs related to the tools directory. labels Jul 2, 2026

StefanStojanovic approved these changes Jul 3, 2026
View reviewed changes

richardlau added the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

github-actionsBot removed the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

trivikr closed this Aug 22, 2026

build,win: fix small-icu build with ClangCL
63c4939
Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot added i18n-api Issues and PRs related to Node.js internationalization support. icu Issues and PRs related to the ICU dependency. needs-ci PRs that need a full CI run. tools Issues and PRs related to the tools directory. labels Jul 2, 2026

StefanStojanovic approved these changes Jul 3, 2026
View reviewed changes

richardlau added the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

github-actionsBot removed the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

trivikr closed this Aug 22, 2026

build,win: fix small-icu build with ClangCL
63c4939
Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot added i18n-api Issues and PRs related to Node.js internationalization support. icu Issues and PRs related to the ICU dependency. needs-ci PRs that need a full CI run. tools Issues and PRs related to the tools directory. labels Jul 2, 2026

StefanStojanovic approved these changes Jul 3, 2026
View reviewed changes

richardlau added the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

github-actionsBot removed the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

trivikr closed this Aug 22, 2026

build,win: fix small-icu build with ClangCL
63c4939
Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot added i18n-api Issues and PRs related to Node.js internationalization support. icu Issues and PRs related to the ICU dependency. needs-ci PRs that need a full CI run. tools Issues and PRs related to the tools directory. labels Jul 2, 2026

StefanStojanovic approved these changes Jul 3, 2026
View reviewed changes

richardlau added the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

github-actionsBot removed the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

trivikr closed this Aug 22, 2026

build,win: fix small-icu build with ClangCL
63c4939
Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot added i18n-api Issues and PRs related to Node.js internationalization support. icu Issues and PRs related to the ICU dependency. needs-ci PRs that need a full CI run. tools Issues and PRs related to the tools directory. labels Jul 2, 2026

StefanStojanovic approved these changes Jul 3, 2026
View reviewed changes

richardlau added the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

github-actionsBot removed the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

trivikr closed this Aug 22, 2026

build,win: fix small-icu build with ClangCL
63c4939
Signed-off-by: moluopro <moluopro@qq.com>

nodejs-github-bot added i18n-api Issues and PRs related to Node.js internationalization support. icu Issues and PRs related to the ICU dependency. needs-ci PRs that need a full CI run. tools Issues and PRs related to the tools directory. labels Jul 2, 2026

StefanStojanovic approved these changes Jul 3, 2026
View reviewed changes

richardlau added the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

github-actionsBot removed the request-ci Add this label to start a Jenkins CI on a PR. label Jul 6, 2026

trivikr closed this Aug 22, 2026

Uh oh!

Uh oh!

Conversation

moluopro commented Jul 2, 2026

Reproduction

Uh oh!

nodejs-github-bot commented Jul 2, 2026

Uh oh!

StefanStojanovic left a comment

Choose a reason for hiding this comment

Uh oh!

nodejs-github-bot commented Jul 6, 2026

Uh oh!

trivikr commented Aug 21, 2026

Uh oh!

moluopro commented Aug 21, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

trivikr commented Aug 22, 2026

Uh oh!

trivikr commented Aug 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

moluopro commented Jul 2, 2026

Reproduction

Uh oh!

nodejs-github-bot commented Jul 2, 2026

Uh oh!

StefanStojanovic left a comment

Choose a reason for hiding this comment

Uh oh!

nodejs-github-bot commented Jul 6, 2026

Uh oh!

trivikr commented Aug 21, 2026

Uh oh!

moluopro commented Aug 21, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

trivikr commented Aug 22, 2026

Uh oh!

trivikr commented Aug 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

moluopro commented Jul 2, 2026

Reproduction

Uh oh!

nodejs-github-bot commented Jul 2, 2026

Uh oh!

StefanStojanovic left a comment

Choose a reason for hiding this comment

Uh oh!

nodejs-github-bot commented Jul 6, 2026

Uh oh!

trivikr commented Aug 21, 2026

Uh oh!

moluopro commented Aug 21, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

trivikr commented Aug 22, 2026

Uh oh!

moluopro commented Aug 21, 2026•
edited
Loading

moluopro commented Aug 21, 2026•
edited
Loading

moluopro commented Aug 21, 2026•
edited
Loading

moluopro commented Aug 21, 2026•
edited
Loading