Compilation error when using MbedTLS 4.0.0 MSVC static build

[tawmoto]

I did this

Hi, MbedTLS 4.0.0 was released in November 2025 and I am trying to build curl using it.

I ran bulding command

cmake ^
  -DCURL_TARGET_WINDOWS_VERSION=0x0601 ^
  -DBUILD_CURL_EXE=OFF ^
  -DBUILD_SHARED_LIBS=OFF ^
  -DENABLE_ARES=ON ^
  -DCMAKE_PREFIX_PATH="C:\Sources\build_c-ares_release\prefix_dir;C:\Sources\build_mbedtls_release\prefix_dir" ^
  -DCURL_DISABLE_LDAP=ON ^
  -DCURL_DISABLE_TELNET=ON ^
  -DCURL_DISABLE_DICT=ON ^
  -DCURL_DISABLE_FILE=ON ^
  -DCURL_DISABLE_TFTP=ON ^
  -DCURL_DISABLE_LDAPS=ON ^
  -DCURL_DISABLE_RTSP=ON ^
  -DCURL_DISABLE_POP3=ON ^
  -DCURL_DISABLE_IMAP=ON ^
  -DCURL_DISABLE_SMTP=ON ^
  -DCURL_DISABLE_GOPHER=ON ^
  -DCURL_DISABLE_NTLM=ON ^
  -DENABLE_IPV6=ON ^
  -DCURL_USE_LIBSSH2=OFF ^
  -DCURL_ZLIB=OFF ^
  -DCURL_USE_MBEDTLS=ON ^
  -DUSE_LIBIDN2=OFF ^
  -DUSE_NGHTTP2=OFF ^
  -DCURL_USE_SCHANNEL=OFF ^
  -DCURL_USE_LIBPSL=OFF ^
  -DCURL_STATIC_CRT=ON ^
  -DCURL_CA_PATH="none" ^
  -DBUILD_LIBCURL_DOCS=OFF ^
  -DBUILD_MISC_DOCS=OFF ^
  -DENABLE_CURL_MANUAL=OFF ^
  -DCMAKE_INSTALL_PREFIX="{install_dir}" ^
  -G "Ninja" ^
  -DCMAKE_BUILD_TYPE=Release ^
  -DCMAKE_STATIC_LINKER_FLAGS="/SUBSYSTEM:CONSOLE,6.01" ^
  -DCMAKE_C_FLAGS="/guard:cf" ^

I get this error

12:15:04     [DEBUG]   CMake Error at C:/TOOLs/cmake/3.27.2/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
12:15:04     [DEBUG]   Could NOT find MbedTLS (missing: MBEDCRYPTO_LIBRARY) (found version
12:15:04     [DEBUG]   "4.0.0")
12:15:04     [DEBUG]   Call Stack (most recent call first):
12:15:04     [DEBUG]   C:/TOOLs/cmake/3.27.2/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
12:15:04     [DEBUG]   CMake/FindMbedTLS.cmake:80 (find_package_handle_standard_args)
12:15:04     [DEBUG]   CMakeLists.txt:797 (find_package)

Maybe because MbedTLS changed the target names for their crypto libs?
https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-4.0.0/docs/4.0-migration-guide.md#using-mbed-tls-as-a-cmake-subproject

I expected the following

Compilation OK

curl/libcurl version

curl 8.18.0

operating system

Windows-10.0.17763

[vszakats]

Thanks for the report. Oddly this doesn't happen in CI or my local tests (both
fairly default builds). These builds are creating both libmbedcrypto.a and
libtfpsacrypto.a (also for .pc files).

Can you share how your mbedTLS 4 was build?

[tawmoto]

Thank you for the reply also.
Locally works on my machine also, very strangely, but I have Win11. It fails on the CI with Win10 and another Win 32bit. (I think it's Win7)

I built mbedTLS with simple flags, nothing special. (sorry for the formatting, it's from an YML that contains the building flags)

      -DENABLE_TESTING=OFF
      -DCMAKE_POLICY_DEFAULT_CMP0091=NEW
      -DCMAKE_INSTALL_PREFIX={install_dir}
      -G"Ninja"
      -DCMAKE_STATIC_LINKER_FLAGS=/SUBSYSTEM:CONSOLE,6.01
      -DCMAKE_BUILD_TYPE=Release
      -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded
      -DCMAKE_C_FLAGS="/guard:cf /D_CRT_SECURE_NO_WARNINGS"

LE: this is what I get from building mbedTLS on Windows on 4.0 compared to 3.6 (mbedcrypto.lib is renamed in 4.0)

[vszakats]

Thanks! It was my random guess that the mbedTLS compatibiity build logic
is missing or broken for MSVC. Confirmed by the screenshots.

Supporting the v4 naming scheme is in itself fine, but supporting both v3 and
v4 (without these compatibility fallbacks) at the same time makes things both
super complex and fragile. mbedTLS thought of that, and kept the old name
to make this transition smooth, but due to this bug, it doesn't work for MSVC
static builds.

This logic is incorrectly assuming unixy library names:
https://github.com/Mbed-TLS/mbedtls/blob/v4.0.0/library/CMakeLists.txt#L275-L282

It looks like something to report to mbedTLS.

edit: it only seems to affect static libraries. Compatibility code for shared
libraries seems to account for MSVC and looks correct (though I haven't tried.)

In the meantime a workaround is either making a copy of tfpsacrypto.lib
to mbedcrypto.lib, or point the curl build explicitly to the libraries via
MBEDTLS_* variables. The former is probably simpler.

edit 2: another workaround is to use pkg-config to detect mbedTLS via
PKG_CONFIG_PATH=path/to/mbedtls4/lib/pkgconfig. It works because
mbedcrypto.pc exists and points to the new library name. Downside is
that pkg-config isn't commonly used on Windows.

[vszakats]

@tawmoto Is #20617 working for you as a fix?

[tawmoto]

Thank you very much for the patch, the PR looks nice, especially that you added libtfpsacrypto as searched lib.

I have to create a curl patch with your change and integrate in our CI (not easy) and then I can get back with an answer. So most probably tomorrow, but in the meantime I will create a copy of tfpsacrypto.lib
to mbedcrypto.lib and see how it works on the CI.

Definetely it's a bug on mbedTLS, a .a file extension is not for Windows. :-) I will open a bug on their side also.
Thank you for all your help.

[tawmoto]

Hi Viktor,

I wanted to confirm that copying the file works as expected (workaround 1). Should I proceed now with testing the changes from your PR?
My main question is whether this PR is intended to be merged into the master branch, or if it was created only as a temporary/test change for my specific case.

I believe the PR should be merged into master, especially since mbedTLS has stated that version 3.x will be deprecated at some point. Because of that, I’m unsure whether it makes sense to test my setup using the PR if it’s not going to be merged.

Thank you in advance.

[vszakats]

I wanted to confirm that copying the file works as expected (workaround 1). Should I proceed now with testing the changes from your PR? My main question is whether this PR is intended to be merged into the master branch, or if it was created only as a temporary/test change for my specific case.

I believe the PR should be merged into master, especially since mbedTLS has stated that version 3.x will be deprecated at some point. Because of that, I’m unsure whether it makes sense to test my setup using the PR if it’s not going to be merged.

Agree, my intent is to merge it to master. It's a valid workaround for
an upstream issue. It also fits indeed into a future update when the old
mbedcrypto name disappears. Also seems harmless once mbedTLS
fixed this on their side.

If you could confirm it working, it'd be helpful!

[tawmoto]

@vszakats I tested and your patch works great, thank you very much. I think for the moment I will keep your patch and delete the workaround solution, as I don't want to alter with the binaries from mbedTLS.

I really hope you include the patch in the next release and thank you again.:)