Commits on Oct 26, 2022

1. 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/

   Jon Gjengset committed Oct 26, 2022
   Configuration menu

   • View commit details
   • Copy full SHA for 527955e
   • Browse repository at this point

   Copy the full SHA

   527955e View commit details

   Browse the repository at this point in the history