We previously disabled this based on a now-closed issue from 2015 [0].
I think enough time has passed that we can give it a shot again, given
that the in the worst case scenario we revert, and in the best case
scenario we get a performance boost.
[0]: https://github.com/rust-lang/rust/issues/30181
As of Rust 1.67.0, the cargo-clippy binary now relies on the rustc_private
libraries [0], so let's do the RPATH fixup to it too.
I've also added a comment to explain the RPATH situation, as it took me
a bit to figure out.
[0]: https://github.com/rust-lang/rust-clippy/pull/9541
ripgrep is a very popular grep replacement (similar to fd and find)
and wezterm is a popular terminal emulator which has a big codebase with
lots of features tested (it also broke in the past multiple times on
rustc upgrades.).
This reverts commit edfbbaf282.
I mistakingly believed that once 1.66.0 was used to bootstrap, we'd be
able to remove libiconv from rustc's build-time dependency tree on Darwin.
Sadly, this isn't the case, because src/tools/bootstrap depends on libc.
Additionally, it seems that my assessment in b1834a461e
was wrong -- *any* dependency on `libc` will cause a requirement on
libiconv, due to rustc unconditionally linking every library specified
in `link` directives, no matter if the function is actually used.
This was worked around somewhat in https://github.com/rust-lang/libc/pull/2944
by not linking libiconv if libc is only a dependency of std, but this
doesn't apply when `libc` is a dependency of anything else.
Maybe one day we'll just rip out libiconv from `libc` entirely (or hide it
behind a feature flag), but for now, we can just keep it in `buildRustPackage`'s
`buildInputs` by default.
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.
