Change:
Hi there, In we use to try and keep our crate's linking instructions up-to-date across supported platforms. We've noticed that in some build configurations the output can change in surprising ways. For instance, using rustc nightly (1.70.0) on Windows (x8664-pc-windows-msvc) in a configuration driven by we see many consecutive duplicate libraries in the output. I understand duplicates are to be expected, and can be meaningful on some platforms, but seeing so many consecutive repeats seems unexpected and unlikely to be meaningful for the build process. Is this perhaps a regression? Or are we making a mistake by relying on the stability of this output across versions/build configurations? This feature is as having a known prefix to "make it easier to fetch the output." leading to the idea that it is expected to be machine consumable. I tried this code: I expected to see this happen: A list produced, with some duplicates (e.g. multiple ), but not many consecutive duplicates. E.g.: Instead, this happened: A list with many consecutive duplicates is produced: </detailsrustc nightly (1.70.0) on Windows (x8664-pc-windows-msvc) in a configuration. rustc nightly (1.70.0) on Windows (x8664-pc-windows-msvc) in a configuration. Project: Build task: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hm, I thought we usually removed consecutive duplicates but apparently only in release. A workaround would be to do so manually. For the msvc targets all duplicates can be removed so long as the order is preserved. This isn't true of many other targets though. It would be much better to have a proper fix though.
Thanks for the quick reply :-) That's we landed on for the short term :+1: Great, thanks for clarifying.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
claim
Error: Parsing assign command in failed: ...' assign' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Thanks !

Discussion:
let mut lib_args: Vec<_> = all_native_libs .iter() .filter(|l| relevant_lib(sess, l)) <ins> // Deduplication of successive repeated libraries, see rust-lang/rust#113209 // // note: we don't use PartialEq/Eq because NativeLib transitively depends on local // elements like spans, which we don't care about and would make the deduplication impossible .dedup_by(|l1, l2| l1.name == l2.name && l1.kind == l2.kind && l1.verbatim == l2.verbatim) </ins> .filter_map(|lib| { let name = lib.name; match lib.kind {

all: $(RUSTC) --crate-type rlib -lbar_cli bar.rs <del> $(RUSTC) foo.rs -lfoo_cli --crate-type staticlib --print native-static-libs 2>&1  </del> <ins> $(RUSTC) foo.rs -lfoo_cli -lfoo_cli --crate-type staticlib --print native-static-libs 2>&1  </ins> | grep 'note: native-static-libs: '  | sed 's/note: native-static-libs: (.*)/1/' > $(TMPDIR)/libs.txt

cat $(TMPDIR)/libs.txt | grep -F "systemd" # in foo.rs cat $(TMPDIR)/libs.txt | grep -F "bar_cli" cat $(TMPDIR)/libs.txt | grep -F "foo_cli" <ins> # make sure that foo_cli and glib-2.0 are not consecutively present cat $(TMPDIR)/libs.txt | grep -Fv "foo_cli -lfoo_cli" cat $(TMPDIR)/libs.txt | grep -Fv "glib-2.0 -lglib-2.0" </ins>

// Obviously makes no sense but... unsafe { g_free(std::ptr::null_mut()); <ins> g_free2(std::ptr::null_mut()); </ins> } left + right }

extern "C" { fn g_free(p: *mut ()); } <ins> #[link(name = "glib-2.0")] extern "C" { fn g_free2(p: *mut ()); } </ins>