fix: gate Electron's extra Win SDK siso headers on target OS, not host#840
Merged
codebytere merged 1 commit intomainfrom Apr 8, 2026
Merged
fix: gate Electron's extra Win SDK siso headers on target OS, not host#840codebytere merged 1 commit intomainfrom
codebytere merged 1 commit intomainfrom
Conversation
The mswsock.h / Lm.h additions to the win_toolchain :headers input set were guarded by 'if runtime.os == "windows"'. When cross-compiling Windows on a Linux host (target_os=win, host=linux), that block is skipped, so siso never uploads those headers to the RBE worker and libuv's win/tty.c (and friends) fail with 'mswsock.h not found'. Use win_sdk.enabled(ctx) instead, which checks target_os == win — the same predicate Chromium's own build/config/siso/win_sdk.star uses to populate :headers in the first place. Also guard on sdk_version and the :headers key actually being present so this is a no-op when the upstream config didn't set them up (e.g. before gn_logs.txt exists).
MarshallOfSound
added a commit
to electron/electron
that referenced
this pull request
Apr 8, 2026
…main.star
- windows-publish.yml: move all three publish jobs to the Linux runner +
ghcr.io/electron/build container (matching build.yml). The publish
segment was regenerated from -build.yml and now assumes a Linux host;
leaving releases on Windows runners would have broken them.
- build-electron/action.yml: drop the Profile Windows Toolchain step.
profile_toolchain.py reads installed_software.json (a Windows-host WMI
dump that no longer exists); upload.py's consumer of the resulting
windows_toolchain_profile.json is gated on sys.platform == 'win32' so
it's skipped on the Linux host anyway.
- pipeline-segment-electron-{build,publish}.yml: drop the
rm -rf vs_files* — the checkout cache doesn't include the toolchain,
so this was a no-op. Keep the e d vs_toolchain.py update --force which
actually fetches it.
- Drop build/siso/main.star + ELECTRON_BUILD_TOOLS_MAIN_STAR and bump
BUILD_TOOLS_SHA to 03f1603 (electron/build-tools#840), which has the
win_sdk.enabled() gate so the in-repo override is no longer needed.
codebytere
approved these changes
Apr 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
mswsock.h/Lm.hadditions to the win_toolchain:headersinput set were guarded byif runtime.os == "windows". When cross-compiling Windows on a Linux host (target_os=win, host=linux), that block is skipped, so siso never uploads those headers to the RBE worker and libuv'swin/tty.c(and friends) fail with'mswsock.h' file not found.Use
win_sdk.enabled(ctx)instead, which checkstarget_os == "win"— the same predicate Chromium's ownbuild/config/siso/win_sdk.staruses to populate:headersin the first place. Also guard onsdk_versionand the:headerskey actually being present so this is a no-op when the upstream config didn't set them up (e.g. beforegn_logs.txtexists on a clean build).Needed for electron/electron#50796 (Windows cross-compile on Linux), which currently carries an in-repo copy of this file and can drop it once this lands.