2024-07-17 06:37 AM - edited 2024-07-17 07:40 AM
Hello!
Our project is supposed to use C++17 features.
When linking C++17 compiled objects against TouchGFX Designer's distributed binaries (eg: touchgfx_core.a), linkage fails, because the touchgfx binaries appear to be compiled against the c++14 standard, not c++17.
Compiling with IAR 9.30.1, having the C++17 compiler flag ("libc++" in IAR parlance) set, the following error is thrown during linkage.
Error[Li009]: runtime model conflict: Module ListLayout.o(touchgfx_core.a) specifies that '__CPP_Library' must be 'DLib', but module [hidden-name].o has the value 'libc++'
We are using TouchGFX 4.23.2 which according to the date of this post by ST Employee @LouisB, we should have no issue linking its objects against C++17 objects compiled by IAR.
However, when inspecting the distributed binary from ST (TouchGFX\4.23.2\touchgfx\lib\core\cortex_m7\IAR9.x\touchgfx_core.a), we can clearly see that it was compiled with C++14, and not C++17:
__CPP_Exceptions.Disabled __CPP_Language.C++14 __CPP_Library.DLib __CPP_Runtime.1 __SystemLibrary.DLib __dlib_version.6
Perhaps the wrong binaries were distributed with this release of touchgfx?
Solved! Go to Solution.
2024-07-18 02:29 AM
Hello @se_stacyg ,
Unfortunately, the information on the thread you mentioned was misleading, and I sincerely apologize for that. TouchGFX only uses the language features of C++98, therefore, it should be safe to use newer versions for compiling it. In the case of IAR, weirdly, it does not allow you to mix C++14 and C++17, and as you mentioned, currently touchgfx_core.a is compiled using C++14.
I tried to compile the project using C++17 with STM32CubeIDE and Keil MDK, and both were successful with no errors. But, sadly, IAR is not capable of doing the same process. (IAR C/C++ Development Guide)
Best regards,
2024-07-18 12:45 AM
Hi @se_stacyg
sorry cant help with your problem but was wondering what application you use to browse binaries - shown in the screenshot. Thanks.
2024-07-18 02:29 AM
Hello @se_stacyg ,
Unfortunately, the information on the thread you mentioned was misleading, and I sincerely apologize for that. TouchGFX only uses the language features of C++98, therefore, it should be safe to use newer versions for compiling it. In the case of IAR, weirdly, it does not allow you to mix C++14 and C++17, and as you mentioned, currently touchgfx_core.a is compiled using C++14.
I tried to compile the project using C++17 with STM32CubeIDE and Keil MDK, and both were successful with no errors. But, sadly, IAR is not capable of doing the same process. (IAR C/C++ Development Guide)
Best regards,
2024-07-18 05:12 AM
This one is called HxD but if you Google "free hex editor" there are oodles of them out there.
2024-07-18 05:13 AM - edited 2024-07-18 05:20 AM
Thanks, Mohammed. Do you have any indication as to when ST will release binaries compiled with a modern language standard? C++14 is a decade old, already, and there exist useful abstractions and containers in the STL which cannot be used without C++17.
Switching toolchain to Keil or something else is not an option for us at this moment.
Isn't it technically against the C++ standard to mix binaries from different language versions like that? It's strange to me that this would be an official solution from ST.
I understand that the library only uses language features from C++98, but that's the only reason that the linker isn't complaining in Keil/etc as far as I can tell. It's kind of a fluke and not a real solution.
2024-07-19 02:08 AM - edited 2024-07-19 02:09 AM
Yes, I totally agree that mixing the binaries is not a good solution, but helping our community is our most important goal, so if there is a chance that a solution might help a case, we won't ignore it.
I'm not sure about the other ST binaries, but in the TouchGFX team, we are planning on using newer standards, however, I cannot tell for sure when they will be available.
I also completely understand that switching toolchains is not a viable solution for you, and I'm really sorry that I can't help you further with that
2024-07-19 05:40 AM
No worries Mohammed, thank you for your help and for explaining the motivation.
There are certainly a lot of ways that C++ can "just work" even if it's not a best practice
It's certainly an interesting discovery anyway that IAR EW seems to be the only toolchain which complains about this!
Thanks again for your help and fingers crossed for updated binaries in a future release.
2024-07-23 02:09 AM
Thank you so much for your kind words
And best of luck to you as well