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.
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
