* Eliminate duplicate passthru definition by moving "tests.version"
* Only compare major version (because the ".0.0" can be truncated
* Special case major version 8 to "1.8" for the comparison
We want -Cforce-frame-pointers=yes when building rustc itself, but the
bootstrap process does not use cargoSetupHook, so set the bootstrap
config option rust.frame-pointers = true if target is not x86_32.
Note that std is unconditionally compiled with frame pointers. See code
comment for elaboration.
See also #399014 for discussion when we enabled frame pointers for C.
When Clang is statically linked against other programs they are unable to
find the headers in Clang's resource directory. Typically the resource
directory is found by searching a path relative to argv[0] but this
would only really work for Clang itself due to each binary having a
separate prefix (and not in Nix because of the full resource directory
being split between multiple derivations and assembled in the wrapper).
Because users of Clang as a library typically only need include in order
for parsing to succeed, let's set that as the resource directory. The LLVM
patch to make this work was sent upstream in llvm/llvm-project#145996,
I intend to land it upstream and drop it from this PR.
The GHC 9.0.2 bindist expects the headers of libffi to be found under
/Applications/XCode.app instead of /Library (which is the case for later
GHC bindists which I copied the code from). Correctly substituting this
path will prevent GHC from using the bundled and thus outdated libffi
headers that are broken for some reason or other.
That these bundled headers were installed was actually a bug in hadrian
which created the bindists because it ignored use-system-libffi before
GHC 9.2. (This was actually the issue I noticed first because it hides
the actual problem: Because GHC installed these headers, GHC found some
version of ffi.h and ffitarget.h instead of correctly failing due to
missing headers which would indicate that package db is broken.) For the
sake of completeness, we can also solve this problem by deleting these
headers in postInstall.
Building dotnet_{8,9}.stage0.vmr when using a non-standard
nixpkgs.localSystem.gcc.arch system config value (such as "znver1")
can lead to the following issue: dotnet/runtime#109611
This PR applies the fix in dotnet/runtime#110554 to dotnet_9 and also
backports it to dotnet_8.
dotnet_10 doesn't need this patch because it's already upstreamed.
Fixes#414786
After #400734 the path to the binutils wrapper is no longer passed via
-B and is instead passed via $PATH. This had the following consequences
for gnat-bootstrap:
- GCC appends $prefix/$triple/bin to collect2's $COMPILER_PATH, which
is where gnat-bootstrap's bundled linker binary is installed. For
normal gcc packages, this has no impact on linker selection because
binutils and gcc are installed to separate prefixes.
- -B paths are also added to $COMPILER_PATH but they appear before
$prefix/$triple/bin. This meant that gnat-bootstrap's collect2 would
find the binutils wrapper before #400734.
- collect2 searches for the linker on $PATH but only after failing to
find it on $COMPILER_PATH. Because #400734 caused the binutils wrapper
path to be removed from $COMPILER_PATH while the bundled linker on
$prefix/$triple/bin was still present, gnat-bootstrap started finding
the bundled linker on $COMPILER_PATH after #400734.
The bundled ld binaries should not be used by builds utilizing
gnat-bootstrap because we need our binutils wrappers to be used so that
RPATH is set correctly. The ld binaries are unused as far as I'm aware,
so remove them from the package so that collect2 finds the binutils
wrapper on $PATH.
