What CMake version are you using?

For me this seems to be an mbedtls bug. See: https://github.com/ARMmbed/mbedtls/issues/1496

@gyuri-szing I'm using cmake version 3.11.1

I have done the some change on mbedtls last week, it works on a partner platform build, the changes like below:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 0ade1d4cb..832e3f1b1 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -72,6 +72,8 @@ function(link_to_source base_name)
         if (CMAKE_HOST_UNIX)
             set(command ln -s ${target} ${link})
         else()
+            string(REPLACE "/" "\\" link "${CMAKE_CURRENT_BINARY_DIR}/${base_name}")
+            string(REPLACE "/" "\\" target "${CMAKE_CURRENT_SOURCE_DIR}/${base_name}")
             if (IS_DIRECTORY ${target})
                 set(command cmd.exe /c mklink /j ${link} ${target})
             else()

Since the tf-m already said it supports the mbedtls-2.7.9, does tf-m need do something to make it support the mbedtls-2.7.9 on Cygwin? or tf-m wait the mbedtls fix it and then upgrade to the latest one, before the mbedtls fix the issue, tf-m add some notes to the tf-m build on Cygwin platform.

Hi @qixiang,

What is going to happen?
We had a discussion with the tech leads and decided to go forward with the current workaround. Meanwhile I contacted the mbedtls team to see when they can fix the issue. When mbdtls is fixed we will disable the workaround and update the documentation and thus support the latest version.

How this could happen?
Unfortunately our CI is Linux only currently and the developer who tested the update is also working on Linux. Thus this problem managed to slip in undetected. Sorry for any inconveniences.

About your fix above:
Yes, this is the correct thing to do. Also the file(TO_NATIVE_PATH calls shall be removed, as these will have no effect on Linux and will not work on Windows. I checked the CMake source-code and it seems the TO_NATIVE_PATH call the same functions as various (e.g. makefile) generator to generate command calls. Since the make tool is usging bash as it's shell both in Cygwin and MingW and bash needs unix like paths, TO_NATIVE_PATH will newer work properly with cmd.exe as is only working with windows paths. So the code is plain wrong.
It must be noted though that the documentation of the file command of CMake is misleading, and any developer working on Linux would fail the same pit. To get a confident answer I had to read the CMake source-code. Luckily CMake is open-source and the quality of the code is good :) . I was able to get an answer in ~30 minutes.

@gyuri-szing Thanks for your detail explanation. I hope we can add the Cygwin build on the CI since a lot of partners use the Cygwin build.

@gyuri-szing for the mbedtls issue, I have submit a PR for it, you could refer: https://github.com/ARMmbed/mbedtls/pull/2473

Thanks for the PR!

It seems the fix has been merged to mbedtls development branch. (See it https://github.com/ARMmbed/mbedtls/commit/7346b312e12a54d77608fc6bb8aa3c55cf046d90?diff=unified).
We may be able to update supported mbedtls version after the next mdbedtls release.

The same issue seems to affect mbedcrypto and this commit has the fix: https://github.com/ARMmbed/mbed-crypto/pull/118/commits/7346b312e12a54d77608fc6bb8aa3c55cf046d90
In TF-M build instructions (https://git.trustedfirmware.org/trusted-firmware-m.git/about/docs/user_guides/tfm_build_instruction.rst ) the following dependencies are defined:

1. mbedtls v2.7.9
2. mbedcrypto v1.1.0

Checking the commits the following releases have the fix:

1. mbedtls shall be ok from version 2.18.0 or 3.0.0p1
2. mbedcrypto shall be ok from version 1.1.0d0 or 2.2.0d0

So it seems we have to update to mbedtls v2.18.0 or later.

Note: there was a patch pushed to work around the issue. See commit: https://git.trustedfirmware.org/trusted-firmware-m.git/commit/BuildMbedtls.cmake?id=a0f505c659e2af2ffa278d215045add711f7f2d8
The workaround only helps when the build is run from git-bash (or Msys/Msys2) or cygwin but will fail when building from cmd.exe (ln command not available).

The proper fix would be to modify the patch linked above to limit the workaround to 2.7 <= version <2.18.0, and update the dependency to 2.18.0 and up.