[package] openssl/3.6.0: test fails on windows shared

[ericLemanissier]

Description

When build openssl 3.6.0 on windows as shared library, the test package failes with Loading legacy provider failed with this error: error:12800067:DSO support routines::could not load the shared library

Package and Environment Details

• Package Name/Version: openssl/3.6.0
• Operating System+version: Windows
• Compiler+version: msvc 194
• Conan version: conan 2.21.0
• Python version: Python 3.13.7

Conan profile

Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=194
os=Windows
[options]
*/*:shared=True

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=194
os=Windows

Steps to reproduce

conan install --require=openssl/3.6.0 --build=missing --build=openssl/3.6.0 -sbuild_type=Release -o*/*:shared=True
conan test recipes/openssl/3.x.x/test_package/conanfile.py openssl/3.6.0 -sbuild_type=Release -o*/*:shared=True

Logs

Click to expand log

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=194
os=Windows
[options]
*/*:shared=True

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=194
os=Windows


======== Launching test_package ========

======== Computing dependency graph ========
Graph root
    openssl/3.6.0 (test package): D:\a\cocorepo\cocorepo\recipes\openssl\3.x.x\test_package\conanfile.py
Requirements
    openssl/3.6.0#89e8af1d4a21afcac0557079d23d8890 - Cache
    zlib/1.3.1#b8bc2603263cf7eccbd6e17e66b0ed76 - Cache
Build requirements
    nasm/2.16.01#a95c9b1a2fc6b32c77f02ed06ad69044 - Cache
    strawberryperl/5.32.1.1#1bdbbe0dd605263f366c4f32b24588fb - Cache
Resolved version ranges
    zlib/[>=1.2.11 <2]: zlib/1.3.1

======== Computing necessary packages ========
Requirements
    openssl/3.6.0#89e8af1d4a21afcac0557079d23d8890:f60426480b018f495764d3139b2d1802bb13a075#89a550a6199a170895531f8377ddf746 - Cache
    zlib/1.3.1#b8bc2603263cf7eccbd6e17e66b0ed76:19e318a866610969ae17aaa36552350ac86725f0#0093a26d3ca96f07c312d7a840e66f75 - Cache
Build requirements
Skipped binaries
    nasm/2.16.01, strawberryperl/5.32.1.1

======== Installing packages ========
zlib/1.3.1: Already installed! (1 of 2)
openssl/3.6.0: Already installed! (2 of 2)
WARN: deprecated: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN: deprecated:     'cpp_info.names' used in: zlib/1.3.1

======== Testing the package ========
Removing previously existing 'test_package' build folder: D:\a\cocorepo\cocorepo\recipes\openssl\3.x.x\test_package\build\msvc-194-x86_64-14-release
openssl/3.6.0 (test package): Test package build: build\msvc-194-x86_64-14-release
openssl/3.6.0 (test package): Test package build folder: D:\a\cocorepo\cocorepo\recipes\openssl\3.x.x\test_package\build\msvc-194-x86_64-14-release
openssl/3.6.0 (test package): Writing generators to D:\a\cocorepo\cocorepo\recipes\openssl\3.x.x\test_package\build\msvc-194-x86_64-14-release\generators
openssl/3.6.0 (test package): Generator 'CMakeDeps' calling 'generate()'
openssl/3.6.0 (test package): CMakeDeps necessary find_package() and targets for your CMakeLists.txt
    find_package(OpenSSL)
    target_link_libraries(... openssl::openssl)
openssl/3.6.0 (test package): Generator 'VirtualRunEnv' calling 'generate()'
openssl/3.6.0 (test package): Calling generate()
openssl/3.6.0 (test package): Generators folder: D:\a\cocorepo\cocorepo\recipes\openssl\3.x.x\test_package\build\msvc-194-x86_64-14-release\generators
openssl/3.6.0 (test package): CMakeToolchain generated: conan_toolchain.cmake
openssl/3.6.0 (test package): CMakeToolchain generated: D:\a\cocorepo\cocorepo\recipes\openssl\3.x.x\test_package\build\msvc-194-x86_64-14-release\generators\CMakePresets.json
openssl/3.6.0 (test package): CMakeToolchain generated: D:\a\cocorepo\cocorepo\recipes\openssl\3.x.x\test_package\CMakeUserPresets.json
openssl/3.6.0 (test package): Generating aggregated env files
openssl/3.6.0 (test package): Generated aggregated env files: ['conanrun.bat', 'conanbuild.bat']

======== Testing the package: Building ========
openssl/3.6.0 (test package): Calling build()
openssl/3.6.0 (test package): Running CMake.configure()
openssl/3.6.0 (test package): RUN: cmake -G "Visual Studio 17 2022" -DCMAKE_TOOLCHAIN_FILE="generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="D:/a/cocorepo/cocorepo/recipes/openssl/3.x.x/test_package" -DOPENSSL_WITH_LEGACY="ON" -DOPENSSL_WITH_MD4="ON" -DOPENSSL_WITH_RIPEMD160="ON" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" "D:/a/cocorepo/cocorepo/recipes/openssl/3.x.x/test_package"
-- Using Conan toolchain: D:/a/cocorepo/cocorepo/recipes/openssl/3.x.x/test_package/build/msvc-194-x86_64-14-release/generators/conan_toolchain.cmake
-- Conan toolchain: CMAKE_GENERATOR_TOOLSET=v143
-- Conan toolchain: Setting CMAKE_MSVC_RUNTIME_LIBRARY=$<$<CONFIG:Release>:MultiThreadedDLL>
-- Conan toolchain: C++ Standard 14 with extensions OFF
-- The C compiler identification is MSVC 19.44.35217.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Conan: Component target declared 'OpenSSL::Crypto'
-- Conan: Component target declared 'OpenSSL::SSL'
-- Conan: Target declared 'openssl::openssl'
-- Conan: Target declared 'ZLIB::ZLIB'
-- Conan: Including build module from 'C:/Users/runner***/.conan2/p/b/opens45fdbad230ab4/p/lib/cmake/conan-official-openssl-variables.cmake'
-- OPENSSL_FOUND: TRUE
-- OPENSSL_INCLUDE_DIR: C:/Users/runner***/.conan2/p/b/opens45fdbad230ab4/p/include
-- OPENSSL_CRYPTO_LIBRARY: libcrypto
-- OPENSSL_CRYPTO_LIBRARIES: libcrypto;ZLIB::ZLIB;crypt32;ws2_32;advapi32;user32;bcrypt
-- OPENSSL_SSL_LIBRARY: libssl
-- OPENSSL_SSL_LIBRARIES: libssl;OpenSSL::Crypto
-- OPENSSL_LIBRARIES: openssl::openssl
-- OPENSSL_VERSION: 3.6.0
-- Configuring done (11.9s)
-- Generating done (0.0s)
-- Build files have been written to: D:/a/cocorepo/cocorepo/recipes/openssl/3.x.x/test_package/build/msvc-194-x86_64-14-release

openssl/3.6.0 (test package): Running CMake.build()
openssl/3.6.0 (test package): RUN: cmake --build "D:\a\cocorepo\cocorepo\recipes\openssl\3.x.x\test_package\build\msvc-194-x86_64-14-release" --config Release
MSBuild version 17.14.23+b0019275e for .NET Framework

  1>Checking Build System
  Building Custom Rule D:/a/cocorepo/cocorepo/recipes/openssl/3.x.x/test_package/CMakeLists.txt
  test_package.c
  digest.c
  digest_legacy.c
  test_package.vcxproj -> D:\a\cocorepo\cocorepo\recipes\openssl\3.x.x\test_package\build\msvc-194-x86_64-14-release\Release\test_package.exe
  Building Custom Rule D:/a/cocorepo/cocorepo/recipes/openssl/3.x.x/test_package/CMakeLists.txt


======== Testing the package: Executing test ========
openssl/3.6.0 (test package): Running test()
openssl/3.6.0 (test package): RUN: Release\test_package
Loading legacy provider failed with this error:
	error:12800067:DSO support routines::could not load the shared library
OpenSSL version: OpenSSL 3.5.3 16 Sep 2025
sha256 digest: 489f719cadf919094ddb38e7654de153ac33c02febb5de91e5345cbe372cf4a0
sha512 digest: c001925fc772b2a1c2a6e6fcfcdb7b25beb5bea4447ce7705f0f523af5c09f41e4b27b602aa9c1efe85b693fb573bec3b180c042e92ba9315ceff8e9605f7daa
sha3 256 digest: 20ad54fdbb61006cd57a05c08223bca9be4bc6d2e40db8e7cedf9d14dd3d8019
sha3 512 digest: d786ef980d259335af265a4bfc27272e0bfe18bbc019f1fac6e0d90f8b2f6d7719f3b5e5c5ccf80d9c08a1444490ab0493f304f28a77fcb64af358cf5442db25
Error testing the digest_legacy() function

ERROR: openssl/3.6.0 (test package): Error in test() method, line 38
	self.run(bin_path, env="conanrun")
	ConanException: Error 1 while executing

[jcar87]

Thanks for reporting this.

Could you attach the full logs (the build log of openssl, as well as the full log for conan test that shows the graph resolution)? Thanks!

[ericLemanissier]

Sorry I messed up the copy/pasting for the test. it is now corrected. The install log can be found here
This problem happens only with 3.6.0, only on windows, and only for */*:shared=True

[ericLemanissier]

@jcar87 I can see that C3I uses tools.cmake.cmaketoolchain:generator=Ninja and user.openssl:windows_use_jom=True. Setting these fixes the issue on my end. EDIT: it does not fix the problem, I was looking at the static build, sorry.

Also, I can see in the failing log "OpenSSL version: OpenSSL 3.5.3 16 Sep 2025" so it must be picking up another openssl dll than the one built. This happens when testing all version of openssl, but it only makes it crash for openssl/3.6.0

FYI, the dll with "ssl" or "crypto" available in path:

/mingw64/bin/libcurl-openssl-4.dll
/mingw64/bin/libssl-3-x64.dll
/mingw64/bin/libcrypto-3-x64.dll
/mingw64/bin/System.Security.Cryptography.ProtectedData.dll
/usr/bin/msys-ssl-3.dll
/usr/bin/msys-crypto-3.dll
/usr/bin/msys-hcrypto-4.dll
/bin/msys-ssl-3.dll
/bin/msys-crypto-3.dll
/bin/msys-hcrypto-4.dll
/c/Windows/system32/libssl-3-x64.dll
/c/Windows/system32/ncryptsslp.dll
/c/Windows/system32/cryptoss.dll
/c/Windows/system32/CryptoWinRT.dll
/c/Windows/system32/libcrypto-3-x64.dll
/c/Windows/system32/libcrypto.dll
/c/Program Files/PowerShell/7/System.Security.Cryptography.OpenSsl.dll
/c/Program Files/PowerShell/7/System.Security.Cryptography.Algorithms.dll
/c/Program Files/PowerShell/7/System.Security.Cryptography.Cng.dll
/c/Program Files/PowerShell/7/System.Security.Cryptography.Csp.dll
/c/Program Files/PowerShell/7/System.Security.Cryptography.dll
/c/Program Files/PowerShell/7/System.Security.Cryptography.Encoding.dll
/c/Program Files/PowerShell/7/System.Security.Cryptography.OpenSsl.dll
/c/Program Files/PowerShell/7/System.Security.Cryptography.Pkcs.dll
/c/Program Files/PowerShell/7/System.Security.Cryptography.Primitives.dll
/c/Program Files/PowerShell/7/System.Security.Cryptography.ProtectedData.dll
/c/Program Files/PowerShell/7/System.Security.Cryptography.X509Certificates.dll
/c/Program Files/PowerShell/7/System.Security.Cryptography.Xml.dll
/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/System.Security.Cryptography.OpenSsl.dll
/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/System.Security.Cryptography.Algorithms.dll
/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/System.Security.Cryptography.Cng.dll
/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/System.Security.Cryptography.Csp.dll
/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/System.Security.Cryptography.Encoding.dll
/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/System.Security.Cryptography.OpenSsl.dll
/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/System.Security.Cryptography.Pkcs.dll
/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/System.Security.Cryptography.Primitives.dll
/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/System.Security.Cryptography.ProtectedData.dll
/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/System.Security.Cryptography.X509Certificates.dll
/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/System.Security.Cryptography.Xml.dll
/c/Program Files/Microsoft Service Fabric/bin/Fabric/Fabric.Code/ClusterAnalysis.TraceAccessLayer.dll
/c/Program Files/Microsoft Service Fabric/bin/Fabric/Fabric.Code/libssl-3-x64.dll
/c/Program Files/Microsoft Service Fabric/bin/Fabric/Fabric.Code/libcrypto-3-x64.dll
/mingw64/bin/libcurl-openssl-4.dll
/mingw64/bin/libssl-3-x64.dll
/mingw64/bin/libcrypto-3-x64.dll
/mingw64/bin/System.Security.Cryptography.ProtectedData.dll
/usr/bin/msys-ssl-3.dll
/usr/bin/msys-crypto-3.dll
/usr/bin/msys-hcrypto-4.dll

[ericLemanissier]

@conan-io/barbarians friendly ping, I miss-clicked on the close button

[uilianries]

I can see in your build log:

Build requirements
    nasm/2.16.01#a95c9b1a2fc6b32c77f02ed06ad69044 - Cache
    strawberryperl/5.32.1.1#1bdbbe0dd605263f366c4f32b24588fb - Cache

The recipe revision for both references does not exist in Conan Center.

λ conan list -r conancenter "nasm/2.16.01#*"
Connecting to remote 'conancenter' anonymously
conancenter
  nasm
    nasm/2.16.01
      revisions
        d0aebbd20ccbb6ad9c9c753ab708098c (2023-12-31 01:34:33 UTC)
        31e26f2ee3c4346ecd347911bd126904 (2025-04-24 08:28:43 UTC)

C:\Users\uilia\AppData\Local\Temp\openssl
λ conan list -r conancenter "strawberryperl/5.32.1.1#*"
Connecting to remote 'conancenter' anonymously
conancenter
  strawberryperl
    strawberryperl/5.32.1.1
      revisions
        4aebb2c51587c02f8d5a18fc1716a6e2 (2022-10-17 17:13:52 UTC)
        8f83d05a60363a422f9033e52d106b47 (2022-10-18 23:03:11 UTC)
        707032463aa0620fa17ec0d887f5fe41 (2024-05-28 16:09:43 UTC)
        8d114504d172cfea8ea1662d09b6333e (2025-07-08 10:37:12 UTC)

Of course, you are not using them for testing, but mostly probably they were used to build your OpenSSL.

[ericLemanissier]

Thanks for the analysis. I'm using my own remote, but these recipes have been exported from conan-center-index without modification. I guess the difference comes from the fact that I did not reduce conandata.yml (by the way, what's the recommended way to do the reduction, is it still to use the deprecated hook KB-H031 ?)
I started the same test but using conan-center as remote : https://github.com/eirikb/proof-of-conan/actions/runs/18589132467/job/52999884443 and it fails in the same way

[jcar87]

It's worth adding some additional diagnostics to check for consistency

diff --git a/recipes/openssl/3.x.x/test_package/CMakeLists.txt b/recipes/openssl/3.x.x/test_package/CMakeLists.txt
index f479eb1a54..a717fe1478 100644
--- a/recipes/openssl/3.x.x/test_package/CMakeLists.txt
+++ b/recipes/openssl/3.x.x/test_package/CMakeLists.txt
@@ -42,3 +42,5 @@ if(OPENSSL_WITH_LEGACY)
       target_compile_definitions(test_package PRIVATE OPENSSL_WITH_RIPEMD160)
     endif()
 endif()
+
+target_compile_options( test_package PRIVATE /showIncludes)
\ No newline at end of file
diff --git a/recipes/openssl/3.x.x/test_package/conanfile.py b/recipes/openssl/3.x.x/test_package/conanfile.py
index 76d2cc26c1..5f74a4d732 100644
--- a/recipes/openssl/3.x.x/test_package/conanfile.py
+++ b/recipes/openssl/3.x.x/test_package/conanfile.py
@@ -36,3 +36,5 @@ class TestPackageConan(ConanFile):
         if can_run(self):
             bin_path = os.path.join(self.cpp.build.bindirs[0], "test_package")
             self.run(bin_path, env="conanrun")
+            self.run("openssl version -d", env="conanrun")
+            self.run("openssl list -providers -verbose", env="conanrun")
diff --git a/recipes/openssl/3.x.x/test_package/test_package.c b/recipes/openssl/3.x.x/test_package/test_package.c
index 8f4148fbf3..786375a46e 100644
--- a/recipes/openssl/3.x.x/test_package/test_package.c
+++ b/recipes/openssl/3.x.x/test_package/test_package.c
@@ -7,6 +7,8 @@ int digest_legacy();
 int main()
 {
        int legacy_result = 0;
+       printf("OpenSSL version str from macro: %s\n", OPENSSL_VERSION_STR);
+
        OPENSSL_init_ssl(0, NULL);
        printf("OpenSSL version: %s\n", OpenSSL_version(OPENSSL_VERSION));

I cant reproduce this on my machine, even with the binary package downloaded from Conan Center

the /showIncludes should show exactly which includes the compiler is seeing (it should be the ones from the package, not somewhere else).

if there's a mismatch between the version reported by the macro and the function, that would indicate the wrong DLL is being loaded.

[ericLemanissier]

Here are the modifications I made : ericLemanissier@c2c2456

Here is the log: https://github.com/ericLemanissier/cocorepo/actions/runs/18592550808/job/53010740366

Somehow the target_compile_options( test_package PRIVATE /showIncludes) did not do anything

openssl version -d shows OPENSSLDIR: "C:\Users\runner***\.conan2\p\b\opens29130ce16532b\p\res" which seems ok to me
openssl list -providers -verboseshows

Providers:
  default
    name: OpenSSL Default Provider
    version: 3.6.0
    status: active
    build info: 3.6.0
    gettable provider parameters:
      name: pointer to a UTF8 encoded string (arbitrary size)
      version: pointer to a UTF8 encoded string (arbitrary size)
      buildinfo: pointer to a UTF8 encoded string (arbitrary size)
      status: integer (arbitrary size)

which also seems ok to me

However, test_package outputs confirms what I said above: the dll is not correct (the includes are correct):

OpenSSL version str from macro: 3.6.0
OpenSSL version: OpenSSL 3.5.3 16 Sep 2025
OpenSSL version: OpenSSL 3.6.0 1 Oct 2025
OpenSSL version: 3.5.3
OpenSSL version: 3.6.0
OpenSSL version: 3.5.3
OpenSSL version: 3.6.0
OpenSSL version: 3.5.3
OpenSSL version: 3.6.0

[jcar87]

is conan running in a process tree where bash is involved? Only thing I can think of is something interfering with conanrun.bat setting of PATH .

The most reliable way to check which DLL is being loaded on Windows is by attaching a debugger - however the process vanishes quickly. I think there is a command line debugger (cdb) - but it requires separate installation.

You may have some luck by adding something like the following (generated with Gemini)

	char *path_value;

    // Get the value of the PATH environment variable
    path_value = getenv("PATH");

    if (path_value != NULL) {
        printf("Contents of the PATH environment variable:\n%s\n", path_value);
    } else {
        printf("PATH environment variable not found.\n");
    }

in my case I can see the bin folders for both openssl and zlib are ahead of everything else. Some other inconsistency to look out for is mixed use of : and ; (that may indicate some misbehaved conversions with bash shells)

target_compile_options(test_package PRIVATE /showIncludes)
target_link_options(test_package PRIVATE /VERBOSE:LIB)

this works for me and correctly prints the included files and the library files it found (however this being windows, the DLL being loaded will be determined by the encoded data inside the .lib)

[ericLemanissier]

Indeed it was running from a bash shell. I just migrated the test to a powershell environment, but it sill loads the wrong openssl.
getenv("PATH") returns the following C:\Users\runner***\.conan2\p\b\opensc7db0a614d457\p\bin;C:\Users\runner***\.conan2\p\zlib0853d28c7fc78\p\bin;C:\Program Files\PowerShell\7;C:\Users\runner***\AppData\Roaming\Python\Python313\Scripts;C:\hostedtoolcache\windows\Python\3.13.7\x64\Scripts;C:\hostedtoolcache\windows\Python\3.13.7\x64;C:\Program Files\MongoDB\Server\7.0\bin;C:\vcpkg;C:\tools\zstd;C:\hostedtoolcache\windows\stack\3.7.1\x64;C:\cabal\bin;C:\\ghcup\bin;C:\mingw64\bin;C:\Program Files\dotnet;C:\Program Files\MySQL\MySQL Server 8.0\bin;C:\Program Files\R\R-4.5.1\bin\x64;C:\SeleniumWebDrivers\GeckoDriver;C:\SeleniumWebDrivers\EdgeDriver\;C:\SeleniumWebDrivers\ChromeDriver;C:\Program Files (x86)\sbt\bin;C:\Program Files (x86)\GitHub CLI;C:\Program Files\Git\bin;C:\Program Files (x86)\pipx_bin;C:\npm\prefix;C:\hostedtoolcache\windows\go\1.24.7\x64\bin;C:\hostedtoolcache\windows\Python\3.9.13\x64\Scripts;C:\hostedtoolcache\windows\Python\3.9.13\x64;C:\hostedtoolcache\windows\Ruby\3.3.9\x64\bin;C:\Program Files\OpenSSL\bin;C:\tools\kotlinc\bi which seems ok to me (even if it's truncated at 1024 chars)

I'm now migrating the build of the recipe to powershell instead of bash.

[jcar87]

There are possibly more things to determine or at play:

• This OpenSSL version: OpenSSL 3.5.3 16 Sep 2025 I suspect it comes from the openssl library loaded by the process. You can use dumpbin to determine what DLL name(s) the test_package executable expects to load. If the DLL name does not match exactly what's in the package, that would indicate the linker was linked against a different .lib than the one in the package (passing /VERBOSE:LIB should help)
• The loading of the legacy provider is a separate issue - that's a different DLL, that openssl will load based on config. The package_info() of the recipe should cause the relevant environment variable to be present - but also need to check if something else is setting it. But it's also possible that there are other environment variables at play here (i'd check the OpenSSL documentation)

AFAIK for both cases, the only way to determine the exact DLLs being loaded are to attach a debugger (Linux and macOS would be easier)