As of Xcode 14 Bitcode is deprecated but Apple still accepts apps built
with bitcode if you're still using Xcode 13. Once Apple stops allowing
you to upload apps built with Xcode 13 this argument should be removed.
https://github.com/rust-lang/cc-rs/pull/768
The problem is that the vendor librarian can't handle object modules
compiled with clang-cl -flto. llvm-lib on the other hand can handle
any object modules, which makes it a preferred option.
The method allows flags to be specified that are only applied to
assembly input files, not C files. This is helpful with clang, which
only accepts certain assembly options if the input file is asm, not C.
Rustc defaults to DWARF-2 on some targets, and DWARF-4 on others.
However using -g with the C compiler yields whatever default version the
C compiler prefers.
One side effect is that the DWARF debug info shipped in some libraries
with rustc itself (e.g. libcompiler_builtins and others) have recently
switched to DWARF-5 as a side effect of upgrading the clang version
used on rustc CI. (https://github.com/rust-lang/rust/issues/98746)
Ideally, the preferred DWARF version would be given by the rust compiler
and/or cargo, but that's not the case at the moment, so the next best
thing is something that aligns with the current defaults, although
work in under way to add a rustc flag that would allow to pick the
preferred DWARF version (https://github.com/rust-lang/rust/pull/98350)
The MSVC assemblers don't support using `--` to mark the end of the
options and the start of the "verbatim" file list. When the compiler
family is MSVC with clang-cl, the assembler used will be the standard
MSVC assembler.
As observed in https://github.com/cross-rs/cross/issues/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 https://github.com/rust-lang/cc-rs/pull/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`.
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/
openharmony_ci