Correctly infer ranlib/ar for cross-gcc toolchains #164
Conversation
A second try at alexcrichton#163. 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 will only work if the tools from `binutils` (which follow that convention) are on `$PATH`. I've also updated the logic in line with the `cc` crate to check that the inferred `AR`/`RANLIB` is actually executable before setting it as an override. See also rust-lang/cc-rs#736.
Sometimes `gcc-ar` is broken, so when both are available we should prefer non-gcc-ar. See also rust-lang/cc-rs#741.
|
Gentle nudge on this @alexcrichton — this change has now been released in |
|
Sorry but honestly that seems hastily merged with rust-lang/cc-rs#741 following shortly afterwards. I'd prefer to let that bake with user experience before causing more problems here. |
|
Though after the latest change, this now preserves the existing semantics of preferring the non prefixed binaries. It effectively just adds the gcc-prefixed binaries as another (secondary) alternative to try. The only exception being if the non prefixed binaries don't exist/aren't executable, which is a broken state anyway. |
|
Could this perhaps be exposed through the |
|
You mean have |
|
Gentle nudge on this |
|
Synced with Alex offline, and I'm going to close this and open a new PR that moves |
This PR exposes cc's inferred archiver through a similar mechanism as `get_compiler`: with `get_archiver`/`try_get_archiver`. As part of this, I also realized that cc wouldn't pick up `ARFLAGS`, so I added support for that. Through that, I also realized that there was currently one place where we didn't respect `Build::ar_flags` when ar was called, so I fixed that too. Since ranlib is exposed more or less exactly like ar, I also added a `get_ranlib`/`try_get_ranlib` combination. This is, in part, to enable `openssl-src` to move to re-use `cc`'s AR (and now RANLIB) detection rather than rolling its own. See alexcrichton/openssl-src-rs#164. Note that I didn't re-use `Tool` for the return value for these getter functions, and instead just exposed `Command` directly. `Tool` has a number of relatively compiler-specific things, so it felt wrong to use. One important caveat to this is that `Command::get_program` was only added in Rust 1.57.0, so users on older versions of Rust won't have a way to recover the inferred `ar` program path, but that feels like it's probably okay given that we didn't even expose `get_archive` until now.
|
rust-lang/cc-rs#763 is step 1. |
Note that `Command::get_program` and `Command::get_args` both stabilized in Rust 1.57.0, and so implicitly bump this crate's MSRV. Depends on rust-lang/cc-rs#763. Replaces alexcrichton#164.
|
And #173 is the eventual PR that brings that into openssl-src. |
Note that `Command::get_program` and `Command::get_args` both stabilized in Rust 1.57.0, and so implicitly bump this crate's MSRV. Depends on rust-lang/cc-rs#763. Replaces alexcrichton#164.
Note that `Command::get_program` and `Command::get_args` both stabilized in Rust 1.57.0, and so implicitly bump this crate's MSRV. Depends on rust-lang/cc-rs#763. Replaces #164.
A second try at #163.
The GCC convention is that if the toolchain is named
$target-gnu-gcc, then ranlib and ar will be available as$target-gnu-gcc-ranliband$target-gnu-gcc-arrespectively. The code as written would infer them to be$target-gnu-{ranlib,ar}, which will only work if the tools frombinutils(which follow that convention) are on$PATH.I've also updated the logic in line with the
cccrate to check that the inferredAR/RANLIBis actually executable before setting it as an override.See also rust-lang/cc-rs#736.