Skip to content

Commit ad1f00d

Browse files
nagisathomcc
authored andcommitted
Prefer -ar to -gcc-ar
As observed in cross-rs/cross#1100, in some situations `*-gcc-ar` might actually be just broken. I believe this is most likely just a plain bug in gcc (failing to consider `--disable-lto` configuration option somewhere in their build setup,) but for the time being `*-ar` tends to avoid this problem altogether. Code added in #736 appears to be preferring `*-gcc-ar`, but no strong rationale is given to prefer one over the other. `*-gcc-ar` being outright broken sometimes seems like a rationale strong enough to continue preferring binutils’ `ar`.
1 parent f914e8a commit ad1f00d

File tree

1 file changed

+5
-2
lines changed

1 file changed

+5
-2
lines changed

src/lib.rs

+5-2
Original file line numberDiff line numberDiff line change
@@ -2623,9 +2623,12 @@ impl Build {
26232623
match self.prefix_for_target(&target) {
26242624
Some(p) => {
26252625
// GCC uses $target-gcc-ar, whereas binutils uses $target-ar -- try both.
2626-
// Prefer -gcc-ar if it exists, since that matches what we'll use for $CC.
2626+
// Prefer -ar if it exists, as builds of `-gcc-ar` have been observed to be
2627+
// outright broken (such as when targetting freebsd with `--disable-lto`
2628+
// toolchain where the archiver attempts to load the LTO plugin anyway but
2629+
// fails to find one).
26272630
let mut ar = default_ar;
2628-
for &infix in &["-gcc", ""] {
2631+
for &infix in &["", "-gcc"] {
26292632
let target_ar = format!("{}{}-ar", p, infix);
26302633
if Command::new(&target_ar).output().is_ok() {
26312634
ar = target_ar;

0 commit comments

Comments
 (0)