Repository navigation
Windows Node 26 enable_thin_lto=true breaks MSVC native addon builds (lldltojobs / -flto=thin) #64674
Description
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 warnsD9002and 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:
- Official Windows Node builds that still use MSVC for addons should ship
enable_thin_lto=falsein the config that node-gyp copies, or common.gypishould gate-flto=thin//opt:lldltojobs=…onclang==1(and/or an lld linker), not only onenable_thin_lto.
Impact (downstream)
- Deno/
npminstalls of optional BLE stacks fail hard on Windows under Node 26.5.0. @steve02081504/fount-p2pdocuments whitelisting onlynode-datachannelscripts 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+.
Activity
steve02081504 commentedon Jul 22, 2026
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 commentedon Jul 22, 2026
steve02081504 commentedon Jul 22, 2026
Confirmed on Windows x64, Node
v26.5.0(enable_thin_lto=trueinprocess.config).clD9002-flto=thin, thenLINK : fatal error LNK1117onopt:lldltojobs=2npm@12.0.1bundled) / 13.0.1 (latest)node-gyp rebuildfor@stoprocent/bluetooth-hci-socket@2.2.6succeeds; generatedbuild/config.gypihasenable_thin_lto: "false"/enable_lto: "false"/clang: 0So 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.0bundling node-gyp@12.4.0, which does not include the fix.npm rebuilduses npm's bundled node-gyp, so only installingnode-gyp@latestglobally is not enough for npm-driven builds.What worked here:
(Alternatively use
node-gyp@>=13directly;npx node-gyp@12.4.0 rebuildstill reproduces the original LNK1117.)Deno: after the same environment upgrade,
deno add npm:@stoprocent/bluetooth-hci-socket@2.2.6withallowScriptsfor that package also compiled successfully (enable_thin_lto: "false"in itsbuild/config.gypi). Uncertain whether Deno always picks PATH/node-gypfrom 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 commentedon Jul 22, 2026
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.Pin node-gyp for CI and drop the LTO flags Node 26 leaks into MSVC
chore(deps): support Node.js 26 and drop Node.js 22
chore(deps): support Node.js 26 and drop Node.js 22
chore(deps): support Node.js 26 and drop Node.js 22
fix(ci): node-gyp 13 for Windows/Node 26, don't release cancelled runs
v1.6.0 (#6)
mmomtchev commentedon Sep 18, 2026
Does anyone have a solution for a Nan module that cannot upgrade to node-gyp 13 which will prevent building against older versions of Node? A Nan module must be built separately for each Node version. Besides using different node-gyp versions for different Node versions.