Code change:
return; } <ins> let self_contained_linker = sess.opts.cg.link_self_contained.linker(); // FIXME: some targets default to using `lld`, but users can only override the linker on the CLI // and cannot yet select the precise linker flavor to opt out of that. See for example issue // #113597 for the `thumbv6m-none-eabi` target: a driver is used, and its default linker // conflicts with the target's flavor, causing unexpected arguments being passed. // // Until the new `LinkerFlavor`-like CLI options are stabilized, we only adopt MCP510's behavior // if its dedicated unstable CLI flags are used, to keep the current sub-optimal stable // behavior. let using_mcp510 = self_contained_linker || sess.opts.cg.linker_flavor.is_some_and(|f| f.is_unstable()); if !using_mcp510 && !unstable_use_lld { return; } </ins> // 1. Implement the "self-contained" part of this feature by adding rustc distribution //    directories to the tool's search path. <del> let self_contained_linker = sess.opts.cg.link_self_contained.linker() || unstable_use_lld; if self_contained_linker { </del> <ins> if self_contained_linker || unstable_use_lld { </ins> for path in sess.get_tools_search_paths(false) { cmd.arg({ let mut arg = OsString::from("-B");

Related discussion:
text: The CI tests building with all our supported linkers: Rust's provided , ARM GCC's , and ARM GCC's . It recently encountered an error when using in nightly builds since . The most likely culprit is that the failing version has started to the linker arguments, which was not present in previous working versions. I wonder if we're meant to be adding some other argument to disable adding ? The error occurs with the cortex-m-rt CI and can be reproduced like so: Or viewed in CI . The error is: nightly-2023-07-02 nightly-2023-07-03 bisected to from PR modify labels: +regression-from-stable-to-nightly -regression-untriaged
shows that the default for the target is rust-lld. i wonder if the new code uses the default instead of the linker in -C linker for some reason?
You were not meant to do anything, sorry about that. I'll fix it.
I can't build a toolchain locally, via , which would be complete enough for this test to build. There are issues about missing core/std. I tried on a example, and can also reproduce the issue and investigate more there, and that and work. The code I in is asked to add CLI arguments for a flavor: this asks to link using via a c/c++ compiler, and why is . I assume that flavor is incorrect when using ? (I don't know who the target maintainers are, so I'll also ping the other 2 people involved in : and still work because they result in a non- request, and we don't do anything there as expected. For my own understanding: does use by default maybe ? And if so, I'd expect that explicitly specifying the linker would also fix the issue, à la which seems to work for me ? I'll look into why this surprising flavor is used in this situation, as it seems to be the pre-existing issue here uncovered by the PR, and report back. It could be an issue in the flavor inference, or some information missing in the targets' definitions, and so on.
Technically, the target builds. As a tier 2 target, we would strongly prefer it to not require additional antics to build. There was but I have taken lqd's remarks that this may be just exposed preexisting problems as a reason to set it slightly lower.