Windows Node 26 enable_thin_lto=true breaks MSVC native addon builds (lldltojobs / -flto=thin)

[steve02081504]

Version

• Node.js v26.5.0 (Windows x64)
• process.config.variables: clang=1, enable_thin_lto=true, enable_lto=false, llvm_version=19.1.5
• node-gyp 12.4.0
• Visual Studio 2026 Insiders / MSVC (cl / link.exe)

What goes wrong

Building a native addon with node-gyp rebuild on this Node binary injects Clang/lld thin-LTO flags into the MSVC project:

• compiler: -flto=thin (MSVC warns D9002 and ignores)
• linker: /opt:lldltojobs=2 → LINK : fatal error LNK1117: 选项“opt:lldltojobs=2”中的语法错误

Reproduced while installing @stoprocent/bluetooth-hci-socket@2.2.6 (dependency of @stoprocent/noble / @stoprocent/bleno). The package binding.gyp does not set these flags; they come from Node’s common.gypi LTO conditions once enable_thin_lto is true in the generated build/config.gypi.

Generated addon config.gypi snippet from the failed build:

"clang": 0,
"enable_lto": "false",
"enable_thin_lto": "true",
"lto_jobs": "2",

So the addon build is treated as non-clang MSVC (clang: 0) while still enabling thin LTO options that only make sense for lld.

Expected

Addon builds on Windows with MSVC should not inherit enable_thin_lto / lld-only linker options from the Node binary’s process config when the toolchain is MSVC.

Either:

1. Official Windows Node builds that still use MSVC for addons should ship enable_thin_lto=false in the config that node-gyp copies, or
2. common.gypi should gate -flto=thin / /opt:lldltojobs=… on clang==1 (and/or an lld linker), not only on enable_thin_lto.

Impact (downstream)

• Deno/npm installs of optional BLE stacks fail hard on Windows under Node 26.5.0.
• @steve02081504/fount-p2p documents whitelisting only node-datachannel scripts under Deno to avoid pulling these optional builds.

When fixed: re-test npm rebuild @stoprocent/bluetooth-hci-socket (and Deno --allow-scripts for noble/bleno) on Windows Node 26+.

[steve02081504]

Tracking (fount-p2p)

Hit while Deno/npm tried to build @stoprocent/bluetooth-hci-socket (optional BLE stack for https://github.com/steve02081504/fount-p2p).

Workaround on our side: do not run install scripts for noble/bleno under Deno; whitelist only node-datachannel.

When fixed: re-test on Windows Node 26+
\\�ash
npm rebuild @stoprocent/bluetooth-hci-socket
\
and Deno with --allow-scripts=npm:@stoprocent/noble (or package-equivalent).

[Archkon]

Tracking (fount-p2p)

Hit while Deno/npm tried to build @stoprocent/bluetooth-hci-socket (optional BLE stack for https://github.com/steve02081504/fount-p2p).

Workaround on our side: do not run install scripts for noble/bleno under Deno; whitelist only node-datachannel.

When fixed: re-test on Windows Node 26+ \�ash npm rebuild @stoprocent/bluetooth-hci-socket \ and Deno with --allow-scripts=npm:@stoprocent/noble (or package-equivalent).

This would be fixed by nodejs/node-gyp#3331
Could you try latest version of node-gyp?

[steve02081504]

Confirmed on Windows x64, Node v26.5.0 (enable_thin_lto=true in process.config).

node-gyp	result
12.4.0 (control)	still fails: cl D9002 -flto=thin, then LINK : fatal error LNK1117 on opt:lldltojobs=2
13.0.0 (via npm@12.0.1 bundled) / 13.0.1 (latest)	node-gyp rebuild for @stoprocent/bluetooth-hci-socket@2.2.6 succeeds; generated build/config.gypi has enable_thin_lto: "false" / enable_lto: "false" / clang: 0

So nodejs/node-gyp#3331 does fix the MSVC path.

Caveat for stock Node 26.5.0: the Node install I started from still had npm@11.18.0 bundling node-gyp@12.4.0, which does not include the fix. npm rebuild uses npm's bundled node-gyp, so only installing node-gyp@latest globally is not enough for npm-driven builds.

What worked here:

npm install -g npm@latest   # npm@12.0.1 → bundled node-gyp@13.0.0
# then, in the package:
npm run rebuild             # node-gyp rebuild

(Alternatively use node-gyp@>=13 directly; npx node-gyp@12.4.0 rebuild still reproduces the original LNK1117.)

Deno: after the same environment upgrade, deno add npm:@stoprocent/bluetooth-hci-socket@2.2.6 with allowScripts for that package also compiled successfully (enable_thin_lto: "false" in its build/config.gypi). Uncertain whether Deno always picks PATH/node-gyp from the host npm toolchain vs shipping its own — in this run it clearly used a fixed node-gyp (≥13). I did not re-test Deno against an environment that only has node-gyp 12.4.0.

[steve02081504]

Closing: confirmed fixed by nodejs/node-gyp#3331 (node-gyp >= 13.0.0). Stock Node 26.5.0 still ships an older npm with node-gyp 12.4.0 — upgrade npm (npm install -g npm@latest) or use node-gyp >= 13 for addon builds until that rolls into the Node distribution.