-
Notifications
You must be signed in to change notification settings - Fork 7.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linking to standard library fails when compiling in official Docker container (IDFGH-3326) #5308
Comments
@inkychris please try adding (This should work in release/v4.1 and later Docker images, corresponding toolchain release 2019r2 or later. Earlier versions did not provide |
Sorry, apparently we still don't have the stubs for |
Ah okay, was just about to give this a try. Will add the stubs in manually and see how that goes! |
@inkychris Perhaps you could give a hint about what you are trying to achieve? You can get the program to link this way, which might be useful for some cases (like, configuring autoconf/automake based projects), but you won't get an application which can actually run on the chip this way. |
I have a static library which is built and distributed for multiple platforms and there is also a private unit-test app that tests the library. This is all done in plain makefiles so for the most part, libraries can generally be compiled by swapping out the respective |
@inkychris, is your test app using Catch2? |
Since I receive similar error messages I'll ask for help in this issue. There is a cmake integration guide which i used to integrate the Catch2 in the mentioned esp-idf example. I already tried to add |
@TobiasBoeschMiele Catch2 is header-only, so it should be possible to use it in IDF. You will need to enable exceptions and likely RTTI support in menuconfig. Note that I am assuming that your top level project is an ESP-IDF build system project. If your top level project is a plain CMake project, then please make sure you go through the related section of the docs: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/build-system.html#using-esp-idf-in-custom-cmake-projects and check the related example: https://github.com/espressif/esp-idf/tree/7d75213/examples/build_system/cmake/idf_as_lib |
I'm using gtest but I think the docs @igrr just linked may be useful. I'm guessing I need to compile and link to any missing idf components that the standard library needs like pthread. |
Top level is an esp-idf project. I'm trying to integrate catch2. I'll try to
I'm tinkering with gtest, too. Thanks for sharing your expirience @inkychris. |
So I tried to use the options mentioned @igrr
without success. An example error entry i get looks like this:
This one is very similar to the ones in the description of @inkychris |
I think I'll give up on this and run the tests on PC with gcc. It is high level software anyway so hardware stubbing using a wrapper can be done. |
Just had a similar issue. Would be nice to have this fixed in a coming release of the tool-chain. |
Has this ever been addressed? I am still seeing this issue. |
This should be possible now with
(we'll make it work also without -Wl,-gc-sections in a future release) |
Environment
espressf/idf
Docker image: tagsv3.3.2
(also had other linking issues),release-v4.2
, andlatest
.Problem Description
A linker error is encountered when compiling an application, failing to find symbols which appear to be for pthread. The unresolved symbols are flagged within the standard library rather than client code.
Expected Behavior
Application that doesn't directly use pthread is linked successfully to the standard libraries.
Actual Behavior
Linker failure:
Steps to reproduce
The text was updated successfully, but these errors were encountered: