Skip to content

[openssl] support non-MSVC compilers on Windows via the unix flow - #52809

Draft
omartijn wants to merge 1 commit into
microsoft:masterfrom
omartijn:openssl-clang-windows
Draft

[openssl] support non-MSVC compilers on Windows via the unix flow#52809
omartijn wants to merge 1 commit into
microsoft:masterfrom
omartijn:openssl-clang-windows

Conversation

@omartijn

@omartijn omartijn commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

The port's Windows path always builds through nmake with cl, bypassing toolchains where the triplet selects another compiler (e.g. clang through a chainloaded toolchain, or cross builds from hosts without MSVC tools — the nmake flow cannot run there at all). Same situation as libsodium's msbuild path in #52803.

This PR detects the configured compiler with vcpkg_cmake_get_vars and routes non-cl.exe compilers through the existing unix flow, adding a clang-windows-msvc Configure target that supplies what the environment cannot: the target triple, Windows system defines, CRT selection, Windows link libraries, and the mingw64 perlasm scheme — clang assembles the gas-syntax perlasm output directly to COFF, so the assembly crypto (AES-NI, AVX-512, SHA extensions) stays enabled. Modules/engine DSOs are disabled for this target; the guard limits it to x64 (other architectures would need their own Configure targets).

MSVC and non-Windows builds are unchanged — the nmake flow and its install-pc-files post-processing are byte-identical, only reached through the new compiler check.

Tested: openssl 3.6.3 cross-compiled for x64-windows from a Linux host with clang 22 through this exact port: configure/build/install green for release and debug, producing COFF libcrypto.a/libssl.a with the perlasm objects included (verified T aesni_cbc_encrypt and the aesni/vpaes/avx512 object files in the archive). Related: #52803, #52808.

  • Changes comply with the maintainer guide
  • SHA512s are updated for each updated download — n/a, no source change
  • ./vcpkg x-add-version openssl was run (3.6.3#1)

@omartijn

Copy link
Copy Markdown
Contributor Author

The x64_linux failures (mathgl, octave) are unrelated to this change: both link system Xft through FLTK, and /usr/lib/x86_64-linux-gnu/libXft.so is missing on the current x64-linux CI image — they were only rebuilt here because the openssl port-version bump cascades through their dependency cone. This PR changes nothing on Linux, and all Windows/OSX/Android/arm jobs pass. Filed as #52825 with the evidence.

The port's Windows path always builds through nmake with cl, bypassing
toolchains where the triplet selects another compiler (e.g. clang via a
chainloaded toolchain, or cross builds from hosts without MSVC tools).
Detect the configured compiler with vcpkg_cmake_get_vars and route
non-cl compilers through the unix flow, with a clang-windows-msvc
Configure target supplying the target triple, Windows system defines,
CRT selection, link libraries and the mingw64 perlasm scheme (clang
assembles the gas-syntax perlasm output to COFF, keeping the assembly
crypto enabled).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@omartijn
omartijn force-pushed the openssl-clang-windows branch from 4f423a0 to 3975b3e Compare July 16, 2026 07: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.

2 participants