fix(build): vendor OpenSSL for Windows cross-build #10

Merged

nrupard merged 2 commits from fix/windows-openssl-vendored-fjmcp-8 into main

2026-06-08 01:31:56 +02:00

nrupard commented

2026-06-08 01:08:14 +02:00

Member

Problem

The build-binary-windows.yml workflow fails on the x86_64-pc-windows-gnu cross-build: openssl-sys can't find a cross OpenSSL. The pkg-config crate skips system-library probing when the host and target triples differ, so the mingw cross-compile finds no openssl.pc and aborts. OpenSSL arrives transitively through fj-client / forgejo-api (native-tls) and git2 (openssl-sys).

Fix

Vendor OpenSSL from source for target_os = "windows" by enabling the openssl vendored feature in a Windows-scoped target dependency block, mirroring the existing musl static build. The bundled openssl-src compiles against the mingw toolchain already in the builder image. Scoped to target_os = "windows" so the Linux glibc and musl artifacts link OpenSSL exactly as before. No Cargo.lock change: the crate, version (0.10.80), and vendored source are already locked by the musl block.

Also refreshed the oci-build/Dockerfile.windows NOTE to document the applied fix instead of the prior "validate on first CI run" placeholder.

Validation

The Windows binary build job validates the cross-compile end-to-end on CI.

#FJMCP-8

## Problem The `build-binary-windows.yml` workflow fails on the `x86_64-pc-windows-gnu` cross-build: `openssl-sys` can't find a cross OpenSSL. The `pkg-config` crate skips system-library probing when the host and target triples differ, so the mingw cross-compile finds no `openssl.pc` and aborts. OpenSSL arrives transitively through `fj-client` / `forgejo-api` (native-tls) and `git2` (openssl-sys). ## Fix Vendor OpenSSL from source for `target_os = "windows"` by enabling the `openssl` `vendored` feature in a Windows-scoped target dependency block, mirroring the existing musl static build. The bundled `openssl-src` compiles against the mingw toolchain already in the builder image. Scoped to `target_os = "windows"` so the Linux glibc and musl artifacts link OpenSSL exactly as before. No `Cargo.lock` change: the crate, version (`0.10.80`), and vendored source are already locked by the musl block. Also refreshed the `oci-build/Dockerfile.windows` NOTE to document the applied fix instead of the prior "validate on first CI run" placeholder. ## Validation The Windows binary build job validates the cross-compile end-to-end on CI. #FJMCP-8

nrupard added 1 commit

2026-06-08 01:08:14 +02:00

fix(build): vendor OpenSSL for Windows cross-build

Check / fmt + clippy + build + tests (pull_request) Successful in 31s

Details

e1ecdf9eaf

The Windows x86_64 binary build aborts because openssl-sys can't locate a cross OpenSSL for the x86_64-pc-windows-gnu target: the pkg-config crate skips system-library probing when host and target triples differ, so the mingw cross-compile finds no openssl.pc and fails.

Vendor OpenSSL from source for target_os = "windows" by enabling the openssl `vendored` feature in a Windows-scoped target dependency block, mirroring the existing musl static build. The bundled openssl-src (already in Cargo.lock) compiles against the mingw toolchain in the builder image. Scoped to target_os = "windows" so the Linux glibc and musl artifacts are unaffected, and no Cargo.lock change is needed since the crate, version, and vendored source are already locked by the musl block.

#FJMCP-8

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

nrupard added 1 commit

2026-06-08 01:29:22 +02:00

fix(build): install OpenSSL build toolchain in Windows builder

Check / fmt + clippy + build + tests (pull_request) Successful in 32s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

d184ede56c

Enabling the vendored OpenSSL feature for the Windows target (prior commit) is necessary but not sufficient: the rust-builder-glibc-windows image lacks the toolchain needed to actually compile OpenSSL from source. Unlike the plain rust-builder-glibc base, the -windows variant ships only mingw and a minimal perl-base, so the build still failed in three distinct ways uncovered by running the cross-build locally against the image:

- openssl-src runs `./Configure` then `make`, but make is absent (build aborts with make not found).
- OpenSSL's Configure needs FindBin.pm, which Debian splits out of perl-base; the minimal perl in the image can't run Configure (Can't locate FindBin.pm in @INC).
- A second openssl-sys is compiled for the HOST (linux-gnu), pulled by a build-dependency in the fj-client chain. It is not covered by the target_os = "windows" vendored scoping, so it links system OpenSSL via pkg-config, which the image also lacks (Package openssl was not found).

Install make, perl, libssl-dev, and pkg-config inline in the builder stage, mirroring the FJMCP-4-style musl-tools fallback in Dockerfile.static, until the rust-builder-glibc-windows image bundles them (tracked in FJMCP-5). Verified end-to-end: `just build-windows` now produces a valid PE32+ x86-64 forgejo-mcp.exe.

#FJMCP-8

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>