Open denizzzka opened 1 month ago
I think steps are wrong, you're installing esp-clang in step 1 but then in step 4 you're using clang instead of esp-clang. Following your steps but changing step 4 by esp-clang works for me on cxx/pthread example:
idf.py --build-dir=builddir -D IDF_TOOLCHAIN=esp-clang -D CMAKE_BUILD_TYPE=Debug set-target esp32c3 build
path:
esp-idf/examples/cxx/pthread
@cristianfunes79 thank you very much!
Actually the steps are not wrong, IDF_TOOLCHAIN=clang switches to clang-based toolchain in IDF. If you specify esp-clang
, I think the value is simply ignored and you get a GCC toolchain by default (and no linking error, since we don't have this bug with GCC-based toolchain)
Indeed, build script began to use gcc, but nothing was broken
Clang support is important for me because project will be linked with 3-rd party library built by LLVM
@denizzzka technically, you shouldn't need to build the whole project with Clang to do that. The details will depend on how you are building that library and whether it depends on Clang's libc++, but generally you could use ExternalProject_Add to build your library and then link it to the rest of your app (which could be built with GCC).
technically, you shouldn't need to build the whole project with Clang to do that.
LLVM and gcc compillers sometimes differently treating ABI and stack unwinding. (For example, right now I run into different format of passing struct containing 3 bytes from LLVM to gcc.)
@denizzzka if you can report the details of this struct ABI mismatch issue over at https://github.com/espressif/llvm-project/issues, that would be very much appreciated!
We do intend to use some libraries compiled with GCC (e.g. Wi-Fi driver closed-source libraries) in applications built with LLVM, so we definitely need to fix this type of issues.
As for the stack unwinding, do you have any example of such incompatibility?
@denizzzka if you can report the details of this struct ABI mismatch issue over at https://github.com/espressif/llvm-project/issues, that would be very much appreciated!
Ok. I'm still researching this issue
As for the stack unwinding, do you have any example of such incompatibility?
It was happened on ARM (i.e. not related to ESP): TType
value (libgcc/config/arm/unwind-arm.h) was different for bare-metal targets on LLVM and libgcc. On LLVM it was same as for Linux:
TType = DW_EH_PE_pcrel | DW_EH_PE_indirect;
but recently (~year) it was changed to same as in GNU:
TType = DW_EH_PE_pcrel;
I.e., this is already fixed, but I remember that I had to search for this problem twice - initially and then after they fixed it :-)
Answers checklist.
IDF version.
~maser (8e4454b28)
Operating System used.
Linux
How did you build your project?
Command line with CMake
If you are using Windows, please specify command line type.
None
What is the expected behavior?
Successful compilation
What is the actual behavior?
Linking fails with errors related to libunwind:
Steps to reproduce.
install Clang:
Use any project
3 . Add to
sdkconfig.defaults
in the project root:Build or installation Logs.
No response
More Information.
Without
-D IDF_TOOLCHAIN=clang
build works as expected