Add Espress ld flags to more closely match CMake builds #7293
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jepler
approved these changes
May 2, 2023
|
This should be delayed until ESP-IDF v5 update, and reviewed and redone then. |
|
I'm going to close this since it will be redone with the switch to IDF 5 #6913 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#7280 added a single
-u ...value to Espressif links to force the correct routine to be linked in, instead of a WEAK version.I looked over the output of ninja.build and found several more things that potentially should be added to the links. I've added this in the Espressif
Makefile. I tested with the usual "Internet test" that's in the Learn Guides on an ESP32-S2 and S3, and it works. One of the added-usymbols is relevant to I2C, so I also tried ESp-32S3 I2C with a problematic clock-stretching device and sadly it does not fix things.I am not sure whether these changes are worth it, but they do make the build "more correct" vis-a-vis the CMake builds. Making this a draft since we might not want to merge.
The
FIRSTandLASTflag groups were chosen to imitate what the current link is doing. The wrapping functions also have to be positioned early or the link fails.