When building a cross-compiler, the rustc derivation does some tricks to
only build the standard library and reuse the host's compiler, leading
to much faster build time.
Unfortunately, the way the build system was invoked, it would always
build the `std` crate, whether or not the target supports it. Some
bare-metal targets only support building the `core` and `alloc` crates.
By being more vague about the build command, using `library` instead of
`library/std`, Rust's build system is able to figure out exactly which
crates to build:
https://github.com/rust-lang/rust/blob/1.74.1/src/bootstrap/compile.rs#L370-L412
Oddly enough, the install command still needs to use `library/std`, even
if building just a subset:
https://github.com/rust-lang/rust/blob/1.74.1/src/bootstrap/install.rs#L207
The following command was used to reproduce the original issue. Without
this patch, it leads to a build failure when trying to compile one of
std's dependencies. With the patch it completes succesfully and produces
a working cross-compiler.
nix build --impure --expr '(import ./. {
crossSystem = {
config = "riscv32-none-elf";
rustc.config = "riscv32imc-unknown-none-elf";
};
}).buildPackages.rustc'
It appears that LLVM's build system no longer sets the executable's
rpath to include the faux resource root we pass in, so we need to make
sure cc-wrapper does this.
Files like `pkgs/development/haskell-modules/configuration-ghc-8.10.x.nix`
assume `ghc` always has an `llvmPackages` attribue. Let's expose `null`
value from `ghcjs` to allow it's propagation.
This fixes package evaluation for `ghcjs` packages.
Without the change `swift` build fails on bundled `llvm` on
`staging-next` as:
In file included from /build/src/llvm-project/llvm/lib/Support/Signals.cpp:14:
/build/src/llvm-project/llvm/include/llvm/Support/Signals.h:119:24:
error: unknown type name 'uintptr_t'; did you mean '__intptr_t'?
void CleanupOnSignal(uintptr_t Context);
^~~~~~~~~
__intptr_t
THe change pulls in upstream fix.
