Previously it was failing with:
Compiling cargo v0.67.1 (/build/rustc-1.66.1-src/src/tools/cargo)
error: linking with `/nix/store/gcc-wrapper-11.3.0/bin/cc` failed: exit status: 1
|
= note: /nix/store/binutils-2.39/bin/ld: skipping incompatible /nix/store/zlib-aarch64-unknown-linux-gnu-1.2.13/lib/libz.so when searching for -lz
/nix/store/binutils-2.39/bin/ld: cannot find -lz: No such file or directory
/nix/store/binutils-2.39/bin/ld: skipping incompatible /nix/store/zlib-aarch64-unknown-linux-gnu-1.2.13/lib/libz.so when searching for -lz
collect2: error: ld returned 1 exit status
This change switches to using GCC 11 by default on aarch64-linux, as well as passing `-lgcc` to the linker, per #201485.
See #201254 and #208412 for wider context on the issue.
This reverts commit b6fc00b8f4.
Rust 1.66.0 contains a fix for libiconv being linked unconditionally on macOS, but this only applies to packages that don't depend on older versions of `libc`.
For now, let's go back to including libiconv in `buildInputs` by default for packages that use `buildRustPackage`. As packages bump their `libc` versions, we can eventually stop including it by default, and manually add it where needed.
The "bootstrap" and "installer" crates depend on lzma-sys, which will
build its own version of xz if it can't find the liblzma.pc through
pkg-config. Even though it's used as a library, xz here is a native
build input, as it is used by the build system rather than the end
product.
The main purpose of `makeRustPlatform` is to enable users to override
the `rustc` and `cargo` versions used by the `rustPlatform` derivations.
In all attributes of the result of `makeRustPlatform`, `rustc` and/or
`cargo` are overriden, except in `importCargoLock`. I think this is an
oversight / bug, and passing the received cargo derivation is the right
behaviour.
If `importCargoLock` always using the global cargo package even in
`makeRustPlatform` is the intended behaviour, I think it should be
documented at least in a comment.
Rust binaries are unconditionally linked to libiconv on Darwin (see https://github.com/rust-lang/libc/issues/2870). We already add it as a dependency in `buildRustPackage`, so let's go a step further and propagate it.
A build script crashes:
> cannot produce dylib for `rustc_driver v0.0.0 (/build/rustc-1.63.0-src/compiler/rustc_driver)` as the target `x86_64-unknown-linux-musl` does not support these crate types
The crt-static option selects if the C runtime is linked dynamically or
statically into the resulting binaries.
There is a default value of this setting for each platform, but it is
not always what we want. For example, musl targets are assumed to always
have the C runtime linked statically, but we support both.
In practise, this fixes an error in the pkgsMusl.rustc build:
> cannot produce dylib for `rustc_driver v0.0.0 (/build/rustc-1.63.0-src/compiler/rustc_driver)` as the target `x86_64-unknown-linux-musl` does not support these crate types
