-
Notifications
You must be signed in to change notification settings - Fork 84
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @jonas-schievink (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
If you rebase this on current master CI should pass. We should also add a new job here that just build without cortex-m-rt/.github/workflows/ci.yml Line 80 in 89bdd8c
|
unfortunately not, still getting with the temporary fix for
(several occurrences) and
|
Oh, the examples won't build even on Linux. We should only test that the main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bors r+
310: Only emit link_section for cortex-m r=jonas-schievink a=adamgreig Previously we always emitted `link_section`, even though it only had an effect when our linker script was being used (and only made sense on cortex-m targets). This breaks building the code for a MacOS target, which is occasionally useful for running `cargo check` etc. In the macros crate we don't have the target information available, so instead we continue to emit `link_section` except specifically on MacOS. This keeps the fix from #306 but hopefully resolves the confusion in #74 (comment). Co-authored-by: Adam Greig <adam@adamgreig.com>
special-cased linker section names to satisfy macos linker constraints