- User Since
- Apr 9 2018, 7:07 AM (53 w, 6 d)
Wed, Apr 3
Turned to be a documentation update task. Fixed in https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/661/ .
Mar 13 2019
No. T95 needs deeper investigation to check what cmake version the fix supports and if all aspects are addressed. Response files not only affect the linker but the archiver too.
There was an important bugfix for response file handling merged into cmake 3.9 so we might need to drop support for anything below 3.10.
The response file problem is another ticket. See https://developer.trustedfirmware.org/T95
and what error do you get?
In my test environment I could not re-create any failure. Can you please provide more details about your case?
Feb 28 2019
After extensive testing no blocking issues could be identified and this effort turned to be a documentation update. See https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/661/
All mentioned cmake versions work fine win the build-system..
Feb 27 2019
Thanks for the PR!
Feb 26 2019
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.
Feb 25 2019
For me this seems to be an mbedtls bug. See: https://github.com/ARMmbed/mbedtls/issues/1496
What CMake version are you using?
Feb 7 2019
As a workaround try to make the path shorter. I refer to the directory where the tf-m, the mbedtls and the CMSIS5 working copy is as "work root" hereafter.
For this on windows:
- you can use the subst command map the work root to a drive letter.
- use the mklink command to link (hard link or junction point) the work root into c:\
Feb 6 2019
Feb 1 2019
Note: cmake release CMake 3.9.0-rc1 has an important bugfix for response file handling. Fixing this issue shall be done after build-system is updated to support latest cmake version. See T228.
Nov 19 2018
I wonder what cmake version you used when testing this change. According to my investigations 3.7 and the up-to-date version works different. Also there is an open issue for ARMCLang and response files: See: https://gitlab.kitware.com/cmake/cmake/issues/18457
Please add some details about your tests.
Oct 19 2018
May 22 2018
May 18 2018
After some investigation there seems to be multiple valid environment variable settings available for Keil. Depending on the license type either no configuration is needed, and Keil "automagically" solves the problem based on licensing configuration done in the IDE, or the environment variables need to be set properly.
In tfm_sw_requirement.md we already state (line 17) "Note* ARM compiler specific environment variable may need updating based on specific products and licenses as explained in ...". I think we can not go further than this, since compiler licensing is out of scope for the project, and we already pointed users to the appropriate source of information.
In reflection of all this I plan to take two actions:
- The licensing configuration check shall be removed from the build system. The warning shall be eliminated when the environment variables are missing sine this is a valid configuration.
- Discussion shall be stared to decide how to modify the documentation. It seems to be impossible to come up with something which works for all possible scenarios and licence types, so the change shall focus on making the note mentioned above more visible. In addition it is worth to consider adding a wiki page about this where we list working settings for specific environments.