Skip to content

Unbreak Windows builds: scope vendored OpenSSL to Linux - #52

Merged
sashyo merged 1 commit into
mainfrom
fix/windows-build-openssl
Aug 13, 2026
Merged

sashyo merged 1 commit into
mainfrom
fix/windows-build-openssl

Conversation

@sashyo

@sashyo sashyo commented Aug 13, 2026

Copy link
Copy Markdown
Owner

The Release workflow's three Windows jobs — build-gateway-windows, build-endpoint-windows, build-vpn-msi — all fail at the same point:

warning: openssl-sys@0.9.117: configuring OpenSSL build: 'perl' reported failure with exit code: 255
warning: openssl-sys@0.9.117: openssl-src: failed to build OpenSSL from source
error: failed to run custom build command for `openssl-sys v0.9.117`

This blocks the Windows gateway binary, so the remaining gateways can't be updated.

Cause

openssl = { version = "0.10.81", features = ["vendored"] } was an unconditional dependency. Nothing in the crate uses openssl:: — it's there to make native-tls vendor OpenSSL so Linux builds are static and the .deb needs no system libssl.

But unconditionally, it also forces a from-source OpenSSL build on Windows, where it is neither needed nor buildable under MinGW. native-tls uses SChannel on Windows:

$ cargo tree -i openssl-sys --target x86_64-pc-windows-gnu
openssl-sys v0.9.117
└── openssl v0.10.81
    └── punchd-bridge-rs          ← the explicit dependency, and nothing else

$ cargo tree -i schannel --target x86_64-pc-windows-gnu
schannel v0.1.29
├── native-tls v0.2.18            ← what actually provides TLS on Windows

Fix

Move it under [target.'cfg(target_os = "linux")'.dependencies], with a comment explaining why it exists at all.

Verification

# Windows target — openssl-sys now absent entirely
$ cargo tree -i openssl-sys --target x86_64-pc-windows-gnu
warning: nothing to print.

# Linux target — vendored OpenSSL unchanged
$ cargo tree -i openssl-sys --target x86_64-unknown-linux-gnu
openssl-sys v0.9.117
├── native-tls v0.2.18 …

Linux builds clean and all 54 tests pass. The Windows compile itself needs CI to confirm — no MinGW here — but the dependency that was failing is no longer in the Windows tree.

Note

This line arrived in #48; it was already in the working tree before that work and I carried it along rather than leaving it dangling, flagging it in that PR's description. It appears to have been added for the Linux static build without the Windows consequence being noticed.

… Linux

All three Windows release jobs — gateway, endpoint and VPN MSI — fail with:

    openssl-sys: configuring OpenSSL build: 'perl' reported failure with exit code: 255
    error: failed to run custom build command for `openssl-sys v0.9.117`

Nothing in the crate uses openssl directly. The dependency exists to make
native-tls vendor OpenSSL so Linux builds are static, but as an unconditional
dependency it also forced an OpenSSL source build on Windows, where it is not
needed and does not work under MinGW.

On Windows, native-tls uses SChannel; `cargo tree -i openssl-sys
--target x86_64-pc-windows-gnu` showed the explicit dependency was the only
thing pulling it in. Scoping it to Linux drops it from the Windows tree
entirely and leaves the Linux static build unchanged.
@sashyo
sashyo merged commit 0630b8a into main Aug 13, 2026
2 checks passed
@sashyo
sashyo deleted the fix/windows-build-openssl branch August 13, 2026 03:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant