I made a mistake when trying to add the target prefix to Rust cross
compilers: pkgsCross.aarch64-multiplatform.rustc ended up being called
"aarch64-unknown-linux-gnu-rustc-aarch64-unknown-linux-gnu-1.69.0",
which is a bit verbose.
With this change:
nix-repl> rustc.name
"rustc-1.69.0"
nix-repl> pkgsCross.aarch64-multiplatform.buildPackages.rustc.name
"aarch64-unknown-linux-gnu-rustc-1.69.0"
nix-repl> pkgsCross.aarch64-multiplatform.rustc.name
"rustc-aarch64-unknown-linux-gnu-1.69.0"
As intended.
Fixes: 57e73d23bb ("rustc,rustPlatform.buildRustPackage: broaden platforms")
rustc supports way more platforms than Linux and Darwin. We might not
be able to build it for every platform at the moment, but that's what
meta.broken is for.
There are other platforms that rustc can produce binaries for, but
can't run on itself, so those are listed in the defaults for
buildRustPackage.
Our `rustc.nix` adds a `--target` flag for the host when doing a
host!=target build, but neglects to add a `--target` flag for the
buildPlatform when doing a build!=(host==target) build. This commit
corrects that.
Before rustc 1.68 omitting the --target flag for the buildPlatform
did not cause any problems. As of rustc 1.68, build!=host without a
--target for the build will fail like below (with hundreds more
"cannot find std::" errors.
```
$ nix build -f . -L pkgsCross.aarch64-multiplatform.rustc
...
Copying stage1 library from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / aarch64-unknown-linux-gnu)
Uplifting stage1 library (x86_64-unknown-linux-gnu -> aarch64-unknown-linux-gnu)
Copying stage2 library from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / aarch64-unknown-linux-gnu)
Building stage2 tool rust-analyzer-proc-macro-srv (aarch64-unknown-linux-gnu)
Compiling autocfg v1.1.0
Compiling libc v0.2.135
Compiling cfg-if v1.0.0
Compiling proc-macro2 v1.0.47
Compiling quote v1.0.21
Compiling unicode-ident v1.0.5
Compiling syn v1.0.102
Compiling once_cell v1.15.0
Compiling parking_lot_core v0.9.4
Compiling serde_derive v1.0.145
Compiling hashbrown v0.12.3
Compiling scopeguard v1.1.0
Compiling smallvec v1.10.0
Compiling log v0.4.17
Compiling serde v1.0.145
Compiling rustc-hash v1.1.0
error[E0463]: can't find crate for `std`
error: cannot find macro `println` in this scope
--> /nix/tmp/nix-build-rustc-aarch64-unknown-linux-gnu-1.68.2.drv-0/rustc-1.68.2-src/vendor/libc-0.2.135/build.rs:7:5
|
7 | println!("cargo:rerun-if-changed=build.rs");
| ^^^^^^^
error: cannot find macro `println` in this scope
--> /nix/tmp/nix-build-rustc-aarch64-unknown-linux-gnu-1.68.2.drv-0/rustc-1.68.2-src/vendor/libc-0.2.135/build.rs:16:9
|
16 | println!(
| ^^^^^^^
error: cannot find macro `println` in this scope
--> /nix/tmp/nix-build-rustc-aarch64-unknown-linux-gnu-1.68.2.drv-0/rustc-1.68.2-src/vendor/libc-0.2.135/build.rs:29:13
|
29 | println!("cargo:rustc-cfg=freebsd10")
| ^^^^^^^
```
Our rustc package is not universal, because we only build std for the
host and target platforms. This means that a build graph where cross
is involved will end up with multiple rustc packages in it, so it
would be helpful to have a way to tell them apart, just like we do for
e.g. gcc.
If RUSTFLAGS is set in the environment, Cargo will ignore rustflags
settings in its TOML configuration. So setting RUSTFLAGS=-g (like
separateDebugInfo does) to generate debug info breaks
dynamically-linked Rust packages on musl. This breakage is visible
for any packages that call into C dynamic libraries. If the binary is
linked directly to a C dynamic library, it will fail to build, and if
it depends on a Rust library which links a C dynamic library, it will
segfault at runtime when it tries to call a function from the C
library. I noticed this because pkgsMusl.crosvm is broken for this
reason, since it sets separateDebugInfo = true.
It shouldn't be possible to end up with broken binaries just by using
RUSTFLAGS to do something innocuous like enable debug info, so I think
that, even though we liked the approach of modiyfing .cargo/config
better at the time, it's become clear that it's too brittle, and we
should bite the bullet and patch the compiler instead when targetting
musl. It does not appear to be necessary to modify the compiler at
all when cross-compiling /from/ dynamically-linked Musl to another
target, so I'm only checking whether the target system is
dynamically-linked Musl when deciding whether to make the modification
to the compiler.
This reverts commit c2eaaae50d
("cargoSetupHook: pass host config flags"), and implements the
compiler patching approach instead.
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
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.
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.
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.
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
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
The order of the entries in the manifest generated while installing
rustc depends on the (parallel) build, so let's sort it to make it
deterministic. Also remove install.log from the output.
Co-Authored-By: Jörg Thalheim <joerg@thalheim.io>
