Comments (11)
Seems fine to recommend lld as the default choice, especially with rust-embedded/cortex-m-rt#84 landed, and just mention in the docs (and the .cargo/config comments) how to use gcc instead and why you might want to.
from cortex-m-quickstart.
+1
from cortex-m-quickstart.
Am I missing something? I just removed the linker from my cargo config and it compiled just fine. What is preventing us from making the change now?
from cortex-m-quickstart.
@therealprof the -Z linker-flavor
flag which is required to use rust-lld is unstable and it's not clear if it will be stabilized for the edition release or if we'll land linker flavor inference (rust-lang/rust#52101) before the edition release.
from cortex-m-quickstart.
@japaric I misunderstood your proposal then: I thought rust-lld is the default now and we're recommending using gcc/binutils for linking. What is preventing us from using rust-lld as default?
from cortex-m-quickstart.
@therealprof sorry, I think the RFC title could be more precise: "use rust-lld as the default linker".
For the thumb*
targets rustc, by default, uses arm-none-eabi-gcc
to link programs. quickstart v0.3.3 doesn't change the linker: rustc uses gcc as it normally would.
The proposal is to have a future quickstart release change the linker to rust-lld using .cargo/config. That means that if you clone quickstart and run cargo build --target $T
you'd be using rust-lld.
What is preventing us from using rust-lld as default?
Changing the linker requires passing -Z linker-flavor
to rustc. This flag is unstable and doesn't work on stable or beta. We have a policy that crates should work on stable (or beta) by default and that features that require nightly should be opt-in. Following that policy switching to rust-lld should be opt-in rather than the default.
from cortex-m-quickstart.
What is preventing us from using rust-lld as default?
Changing the linker requires passing -Z linker-flavor to rustc. This flag is unstable and doesn't work on stable or beta. We have a policy that crates should work on stable (or beta) by default and that features that require nightly should be opt-in. Following that policy switching to rust-lld should be opt-in rather than the default.
Sorry for being so imprecise. I meant: What is preventing rustc
from using lld by default? There should be a preference to using llvm parts instead of unrelated external depedencies, no?
from cortex-m-quickstart.
What is preventing rustc from using lld by default?
Changing the default linker of any of the thumb*
targets would be a breaking change (*). Imagine a user that only passes -Wl,-Tlink.x
to the linker (via rustcflags); if we change the default linker from gcc to lld their build would break because lld expects -Tlink.x
(w/o the -Wl,
prefix).
(*) However, everyone who can build a binary is using nightly so it might be OK to do this breaking change without breaking Rust stability promise ("no breaking changes when doing updates on the stable channel). But, I imagine such change would require a rust-lang/rust RFC and getting an OK from all stakeholders. Also, there would need to be a stable mechanism to switch from rust-lld
to arm-none-eabi-gcc
so presumably either -Z linker-flavor
would have to be stabilized or linker flavor inference would have to be implemented before changing the default linker.
from cortex-m-quickstart.
If we don't change it for Rust 2018 edition we'll be stuck with it forever (as approximation for "a long time"). I'd rather break it now instead of having to work around it for the foreseeable future. Unless of course a smarter mechanism is around the corner (*).
Fun fact: I've been using the binutils linker directly all the time (instead of going through gcc) and so the arguments to pass are exactly the same.
(*) Like introspecting the linker args and inferring which linker to use.
from cortex-m-quickstart.
@alexcrichton what would it take (RFC or PR+FCP) to change the default linker of a built-in target? This is technically a breaking change but in this case the change would only break nightly users. More details in #39 (comment).
from cortex-m-quickstart.
An interesting question! It does sound unfortunatley like it'd be a breaking change, so in that sense to do this I think we'd just want to have a concrete handle on what exactly the breakage is (which it sounds like you've got) along with stakeholder buy-in that the breakage is worth it and/or there's a migration path.
In that sense this I think it's up to you whether it requires an RFC or not. The embedded working group likely embodies all the stakeholders here so if there's consenus to do this then it can likely be a PR!
A few things I've found helpful for things like this in the past are:
- An easy flag for nightly users to test out the "to become defaut" behavior. I think this may already be implemented? (if so it'd be good to document here and test locally)
- An easy flag for nightly users to go back to the old behavior if this change is indeed stabilized, just in case unexpected breakage turns up.
Does that make sense?
from cortex-m-quickstart.
Related Issues (20)
- License files missing
- GDB Load Failed Due to Invalid memory.x Flash Layout
- Allocator example broken
- Document on a quickstart guide for Raspberry Pi Pico HOT 1
- Using probe-rs to initialise memory.x HOT 5
- Update VS Code Config to use unified stlink.cfg
- Make this repository a template HOT 4
- Debug have some problems "unknown command: `arm` " HOT 1
- "message": "failed to parse manifest at `/Users/tz/Downloads/cortex-m-quickstart-master/Cargo.toml`", HOT 2
- add a runner to flash program directly HOT 2
- Is it possible to run examples in `qemu`? HOT 1
- Error while following the Embedded Book HOT 2
- How to run the quickstart code on LPCXpresso55S69?
- cargo generate error HOT 3
- Blue Pill Quickstart HOT 5
- probe-rs HOT 1
- Update for stm32l4 dependency causes linker error HOT 3
- Add documentation ARM v8 Baseline and Mainline (Cortex-M23/M33/M35P)
- Documentation or example for the allocator not working HOT 3
- Feature request: Confusing task names HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cortex-m-quickstart.