Seeing the following new warnings pop up on stderr when cargo was bumped
to 1.78:
```
warning: `/build/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
```
which happens to break commitmsgfmt builds in nix (#320294).
closes#320294
Tested the following packages with and without structuredAttrs:
- rust-analyzer: cargo-build-hook, cargo-check-hook
- jujutsu: cargo-nextest-hook
- kornia-rs: maturin-build-hook
Currently we cannot debug rust binaries on darwin (via lldb).
The debug symbols seem to be provided by default in a number of files
in `target/debug/deps/*.rcgu.o`. As far as I can tell these have
hardcoded paths referring to the ephemeral build directory. However,
`split-debuginfo=packed` conveniently produces a `.dSYM` file that can
be copied to `$out/bin/` and immediately provide debugging information.
Fixes https://github.com/NixOS/nixpkgs/issues/262131
Seeing the following new warnings pop up on stderr when cargo was bumped
to 1.78:
```
warning: `/build/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
```
which happens to break commitmsgfmt builds in nix (#320294).
closes#320294
--frozen is stricter than we need in Nixpkgs. If a Cargo.lock is
slightly wrong, or (in my use case) if building a subproject that is
not a member of the top-level workspace, but the correct Cargo.lock
can be entirely resolved from the existing top-level Cargo.lock, it
should be deterministic, and shouldn't cause any problems, to let
cargo generate the new Cargo.lock. This should result in less need to
bother upstreams about fixing their Cargo.lock files in cases where
they could have been automatically fixed.
With `cargoRoot` set to a subdirectory of the source, where the
Cargo.{lock,toml} are found, the final mv would previously fail, since
the build results appear relative to cargoRoot, not to the original
build directory.
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
Cargo will never need to link for the target platform — that'd be for
the package being built to do at runtime. Cargo should know about the
build and host linkers.
This fixes e.g. pkgsCross.musl64.fd from x86_64-linux.
Fixes: 67a4f828b4 ("rust: hooks: fix cross compilation")
> If using a target spec JSON file, the <triple> value is the filename
> stem. For example --target foo/bar.json would match [target.bar].
- https://doc.rust-lang.org/cargo/reference/config.html#target
I've also exposed toRustTargetSpecShort as a public function, because
it's useful to be able to know what the target subdirectory will be.
Currently there is a state of severe confusion in
pkgs/build-support/rust/hooks/ regarding host vs target; right now
there is only "host" defined, but whether it means "host" or
"target" seems to fluctuate.
This commit corrects that, ensuring that all variables come in all
three flavors (build, host, target) and are used consistently with
the nixpkgs convention.
This also fixes the cross-compilation of packages which use
`maturinBuildHook` -- hooks go in `nativeBuildInputs` and are
phase-shifted backwards by one platform, so they need to be careful
about distinguishing between build and host.
Closes#247441
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.
unpackFile doesn't dereference symlinks if cargoDeps is a directory, and
some cargo builds run into permission issues because the files the
symlinks point to are not writable.
Currently cargo-setup-hook instructs the builder upon cargoSha256 or
cargoHash being out-of-date compared to the Cargo.lock file.
The instructions can be simplified a bit, because nowadays it is fine to
keep a hash empty, instead of filling it with
`0000000000000000000000000000000000000000000000000000`.
Nix nowadays outputs SRI hashes, which should usually be placed in
`cargoHash` instead of `cargoSha256`, but the instructions are still
only referring to `cargoSha256`.
Lastly, the output of Nix doesn't include `got: sha256: ` anymore, as it
now outputs `got: sha256-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=`.
It would be nice to make it clear that the trailing `=` is important as
well, so the full example SRI hash is mentioned.
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 breaks the builder when a nix-shell or keepBuildTree is used. The
issue occurs because paths to cargo lockfiles are read with NIX_BUILD_TOP,
which is not reliable.
This breaks a nix-shell because NIX_BUILD_TOP simply is not set, causing
an invalid path to be used. This can be worked around using
NIX_BUILD_TOP=$PWD, but that obviously is not great.
This breaks keepBuildTree because it changes the working directory to a
different path than NIX_BUILD_TOP. Since the lockfiles are copied based
on the working directory, but read based on NIX_BUILD_TOP, this causes
the hook to not be able to find them.
This was solved by both reading these files based on the working directory,
using absolute paths to avoid having to traverse back in the directory tree.
Fixes: #138554
Tell rust if we want our binaries linked statically or dynamically.
Otherwise the compiler will always produce statically linked binaries for musl
targets, as this is the default.
The `checkType` argument of buildRustPackage was not used anymore
since the refactoring of `buildRustPackage` into hooks. This was
an oversight that is fixed by this change.
The check type can also be passed directly to cargoCheckHook using the
`cargoCheckType` environment variable.
