[openssl] support non-MSVC compilers on Windows via the unix flow - #52809
Draft
omartijn wants to merge 1 commit into
Draft
[openssl] support non-MSVC compilers on Windows via the unix flow#52809omartijn wants to merge 1 commit into
omartijn wants to merge 1 commit into
Conversation
3 tasks
omartijn
force-pushed
the
openssl-clang-windows
branch
from
July 9, 2026 09:30
dbc3707 to
4f423a0
Compare
Contributor
Author
|
The x64_linux failures ( |
Victor Romero (vicroms)
marked this pull request as draft
July 11, 2026 08:43
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
force-pushed
the
openssl-clang-windows
branch
from
July 16, 2026 07:58
4f423a0 to
3975b3e
Compare
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
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 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_varsand routes non-cl.execompilers through the existing unix flow, adding aclang-windows-msvcConfigure target that supplies what the environment cannot: the target triple, Windows system defines, CRT selection, Windows link libraries, and themingw64perlasm 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-filespost-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.awith the perlasm objects included (verifiedT aesni_cbc_encryptand the aesni/vpaes/avx512 object files in the archive). Related: #52803, #52808../vcpkg x-add-version opensslwas run (3.6.3#1)