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.

[se_stacyg]

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

[Mohammad MORADI ESFAHANIASL]

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]

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 

 

[GMeur]

Is there anything new? Any plan on releasing a c++17 compatible version of touchgfx?

I'd really like to use std::variant in my project. 

Thanks in advance. 

[ferro]

I guess you mean for IAR specifically. With CubeIDE i use C++20 no problem there.

[GMeur]

Yes, indeed, I'm talking about IAR specifically ;) 

[ferro]

I see, very Unfortunate. Try 4.25.0.

[GMeur]

I'm already working with 4.25.0 sadly…