Distributed TouchGFX binaries fail during linkage with C++17

[se_stacyg]

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? 

[ferro]

Hi @se_stacyg 

sorry cant help with your problem but was wondering what application you use to browse binaries - shown in the screenshot. Thanks.

[Mohammad MORADI ESFAHANIASL · Accepted solution]

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,

[se_stacyg]

This one is called HxD but if you Google "free hex editor" there are oodles of them out there.

[se_stacyg]

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.

[Mohammad MORADI ESFAHANIASL]

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 

[se_stacyg]

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 😁 One of the beauties and simultaneous difficulties with the language. 

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. 🤞