* use finalAttrs instead of rec
* shorten url
* use hash instead of sha256
* use canonicalize-jars-hook (related issue: #278518)
* add meta.mainProgram
Upstream has mainlined this patch, the preprocessor macros take care of only
applying the code where necessary. There is no need for nixpkgs to if-guard it
further.
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.
