Skip to content

Commit 4796486

Browse files
Jon Gjengsetthomcc
Jon Gjengset
authored andcommitted
Correctly infer ranlib/ar from cross-gcc
The GCC convention is that if the toolchain is named `$target-gnu-gcc`, then ar will be available as `$target-gnu-gcc-ar`. The code as written will infer it to be `$target-gnu-ar`, which won't work. I'm not sure why the code that existed was written the way it was -- I don't know of any GCC toolchains where the `-gcc` is stripped out in the name of ar. The file listing on Debian's [GCC 6.x] and [GCC 10.x] all show the binaries using the `$target-gnu-gcc-ar` format, as does Arch Linux's [GCC 12.x]. It may seem odd that the code always adds `-gcc` for that match arm, but this matches what we do for finding `$CC` and `$CXX` where we always inject the GNU prefix when target != host. Also note that there isn't a special `ar` for C++, so even when `self.cpp == true`, we should use `-gcc-ar`. Our saving grace, and likely the reason bug reports haven't come in about this, is that we also checks if the resulting binary name is executable, and if it isn't we fall back to the default AR instead. This means the bad heuristic is likely often masked by the presence of another working default AR. See also alexcrichton/openssl-src-rs#163. [GCC 6.x]: https://packages.debian.org/stretch/gcc [GCC 10.x]: https://packages.debian.org/stable/devel/gcc [GCC 12.x]: https://archlinux.org/packages/core/x86_64/gcc/
1 parent 8daff16 commit 4796486

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

src/lib.rs

+1-1
Original file line numberDiff line numberDiff line change
@@ -2601,7 +2601,7 @@ impl Build {
26012601
} else if self.get_host()? != target {
26022602
match self.prefix_for_target(&target) {
26032603
Some(p) => {
2604-
let target_ar = format!("{}-ar", p);
2604+
let target_ar = format!("{}-gcc-ar", p);
26052605
if Command::new(&target_ar).output().is_ok() {
26062606
target_ar
26072607
} else {

0 commit comments

Comments
 (0)