Open M-Bab opened 1 month ago
Hi @M-Bab !
In some cases you will build xtensa toolchain code with another GCC than provided from the toolchain.
Could you please explain what you want to achieve?
There are my thoughts regarding the ticket:
Well there might be other use-cases but ours is unit testing our code. We run the tests on a local x86 platform with Ceedling/Unity/CMock. So far we never had to care about mismatches of the local x86 gcc in the system and the gcc version of the xtensa toolchain.
This is the first time it breaks.
What do you think about
#if defined(__clang__) && (__has_extension(c_atomic) || __has_extension(cxx_atomic))
#define __CLANG_ATOMICS
#elif __GNUC_PREREQ__(4, 7)
...
@M-Bab , your change looks good!
BTW, did not catch why you need to mix toolchain internals. Anyway, you may be interested in idf.py --preview set-target linux build monitor
command. It's still under development but could be useful for unit testing that does not require esp32 hardware..
BTW, did not catch why you need to mix toolchain internals.
Our unit-tests only run on the host platform - this is an x86 system. And of course it uses the GCC compiler which is installed on the host system. And this can be virtually any modern GCC. We are not mixing toolchains.
Answers checklist.
General issue report
The whole setup is a bit tricky: In some cases you will build xtensa toolchain code with another GCC than provided from the toolchain. In our case it is unit tests we run on x86 platforms compiled with the local GCC. But even outside this scope the xtensa toolchain will run into the problem when upgrading its GCC.
The stdatomic.h (in ~/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20240305/xtensa-esp-elf/xtensa-esp-elf/include/stdatomic.h) tries to determine the right setup for different compilers:
Unfortunately the most recent GCC also replies __has_extension(c_atomic) with true. So we get the define
__CLANG_ATOMICS
which is obviously for Clang. Consequently the build also fails with:And many other errors if stdatomic.h is somehow included. For now I will workaround that by modifying the xtensa toolchain:
But maybe you got a better solution. This issue is also a hint for other users having a similar problem. And to make you aware there is a change necessary when upgrading GCC.