Correctly infer ranlib/ar from cross-gcc

[jonhoo]

The GCC convention is that if the toolchain is named $target-gnu-gcc, then ranlib and ar will be available as $target-gnu-gcc-ranlib and $target-gnu-gcc-ar respectively. The code as written would infer them to be $target-gnu-{ranlib,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 ranlib/ar. The file listing on Debian's GCC 6.x and GCC 10.x all show the binaries using the $target-gnu-gcc-$bin format, as does Arch Linux's GCC 12.x.

This error appears to also be present in the cc crate. There, the -gcc prefix is always stripped (1, 2), and then -ar is appended. But its saving grace is that it also checks if the resulting binary name is executable, and if it isn't falls back to the default AR instead, which means the bad heuristic is likely often masked by the presence of another working default AR. This crate does not (but perhaps it should?).

[sfackler]

binutils provides ar and ranlib without the gcc prefix: https://packages.debian.org/bullseye/amd64/binutils-aarch64-linux-gnu/filelist

[alexcrichton]

Oh sorry I misinterpreted this and misunderstood what's happening, I've pushed a revert to main in the meantime.

I'll follow what the cc crate does here, I've never used the *-gcc-ar executables myself, I've always seen the binutils version as *-ar used. I'll defer to others though for what's best.

[jonhoo]

Hmm, interesting. I still think trying with the gcc prefix is the right thing to do, but maybe we should also make sure we continue to support the binutils ar.

[jonhoo]

Second attempt in https://github.com/alexcrichton/openssl-src-rs/pull/164 that retains binutils support.