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.
It turns out that unlike a normal Unix program, if the --sysroot
option is given more than once, rustc will error rather than using the
last value given. Therefore, we need to ensure we only add our
default --sysroot argument if one hasn't been given explicitly on the
wrapper's command line.
This fixes cross compilation of rustc.
Closes: https://github.com/NixOS/nixpkgs/issues/271736
Fixes: 8b51cdd3be ("rustc: add a compiler wrapper")
Rust 1.74 added support for configuring lints with cargo in a new
"lints" table. This also adds a new possible position to reference the
host workspace.
Fixes#273835
This function is not, and never have been, used anywhere inside nixpkgs, outside of bootstrapping setupcfg2nix itself.
It was added in https://github.com/NixOS/nixpkgs/pull/38778 by @shlevy.
It has no out-of-tree users on Github either. External breakage is not expected.
this makes it a lot easier to create a modified stdenv with a
different set of defaultHardeningFlags and as a bonus allows us
to inject the correct defaultHardeningFlags into toolchain wrapper
scripts, reducing repetition.
while most hardening flags are arguably more of a compiler thing,
it works better to put them in bintools-wrapper because cc-wrapper
can easily refer to bintools but not vice-versa.
mkDerivation can still easily refer to either when it is constructed.
this also switches fortran-hook.sh to use the same defaults for
NIX_HARDENING_ENABLE as for C. previously NIX_HARDENING_ENABLE
defaults were apparently used to avoid passing problematic flags
to a fortran compiler, but this falls apart as soon as mkDerivation
sets its own NIX_HARDENING_ENABLE - cc.hardeningUnsupportedFlags
is a more appropriate mechanism for this as it actively filters
out flags from being used by the wrapper, so switch to using that
instead.
this is still an imperfect mechanism because it doesn't handle a
compiler which has both langFortran *and* langC very well - applying
the superset of the two's hardeningUnsupportedFlags to either
compiler's invocation. however this is nothing new - cc-wrapper
already poorly handles a langFortran+langC compiler, applying two
setup hooks that have contradictory options.
Please Nix CI (OfBorg) with empty set instead of null on non-linux platforms,
where NixOS tests are not supported.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Define package `testScriptBin` that contains the substituted test script.
* Add an `installCheckPhase` to check the result script with ShellCheck.
* Passthru as `references.testScriptBin` to run the
(substituted) test script directly (without VM).
* Drop the logic in build script that detects if
it is run in the Nix sandbox.
* Inline sample application; drop invoke-*.nix.
Format expressions.
* Format with `nixpkgs-fmt`.
* Use multi-line style of set patterns.
Call the samples with `callPackage`.
* Rename `sample` -> `samples`.
* Take individual packages / build helpers directly from the
set pattern.
* Define `cleanSamples` to filter out overriders such as `<pkg>.override`.
added by `callPackage`.
Passthru samples and invocation results for easier debugging.
* Passthru samples, references, directReferences
* Provide tests.trivial-builders.writeStringReferencesToFile with such
samples argument.
After #268458, when setting `enableFakechroot = true` and
`includeStorePaths = false`, some of the store paths were getting
included into the image anyway, thru `bind-paths`.
This resulted in unexpectedly large images.
Now, the images will not contain any store paths under those
circumstances.
Fixed conflict in pkgs/applications/graphics/krita/
krita: 5.1.5 -> 5.2.0
7a40fdc288
, and
treewide: use kde mirror everywhere, don't use pname in download urls
aa15f5066d
The previous find invocation didn't match the root directory, so the
root directory's access and modification time wasn't set to a
deterministic value and the build time leaked into the output.
`make-initrd` replaced `cpio` with `bsdtar` in #165892 because the
former includes the number of hardlinks in the created archive, which
depends on the filesystem (and can also be influenced by `nix-store
--optimise`). The same problem applies to `make-initrd-ng`, so this
commit replaces `cpio` with `libarchive`'s `bsdtar`.
-B must be set to the root directory of avrlibc, otherwise gcc cannot
locate crt objects for some attiny devices. -L trains as set by
bintools-wrapper are not necessary with -B set correctly because gcc
takes care of that, and likewise we can drop the -B train from
cc-wrapper because the one spec is enough.
Setting RUSTFLAGS causes Cargo to ignore other ways of configuring
flags, including the target-specific RUSTFLAGS options. This broke
pkgsCross.musl64.crosvm, and was surprising to users.
Fixes: https://github.com/NixOS/nixpkgs/pull/261727
We keep running into situations where we can't get the right
combination of rustc flags through build systems into rustc.
RUSTFLAGS is the only variable supported across build systems, but if
RUSTFLAGS is set, Cargo will ignore all other ways of specifying rustc
flags, including the target-specific ones, which we need to make
dynamic musl builds work. (This is why pkgsCross.musl64.crosvm is
currently broken — it works if you unset separateDebugInfo, which
causes RUSTFLAGS not to be set.)
So, we need to do the same thing we do for C and C++ compilers, and
add a compiler wrapper so we can inject the flags we need, regardless
of the build system.
Currently the wrapper only supports a single mechanism for injecting
flags — the NIX_RUSTFLAGS environment variable. As time goes on,
we'll probably want to add additional features, like target-specific
environment variables.
A handful of kernel modules use glob patterns to express their
firmware dependencies. (`git grep 'MODULE_FIRMWARE.*\*'`)
Previously, we weren't handling these patterns. Now, we are.
Ideally fetch-yarn-deps could do like some other fetchers and support
using SSL_CERT_FILE if it exists and also only verify integrity on FOD
hash unless using an empty/test hash.
But this should keep at least the same semantics as before the recent
Node.js change to stop using the built-in certificate store in favor of
the system one (which does not exist by default in the build sandbox).
Not sure how this ever worked but tar was trying to archive /proc and /sys, which failed to work.
Since this is never useful for containers to do, we exclude this now in the proot case.
Also fakeroot is not needed when proot is used as it provideds the same feature.
We now cleanly seperate those cases as both are kind of hacks and it's more likely
that the combination will just trigger new bugs.
when bubblewraps tries to link all the required files in etc from the
host to the fhs environment, it will re-create the /etc directory.
It will do so with `0700` permissions. This causes permissions issues
with non-root programs when they need to access configuration in the
environment /etc.
By mounting /etc as a tmpfs early, bwrap will make the directory `0755`
as expected.
Some programs (e.g. nvfetcher) parse the output of nix-prefetch-git as
JSON. However, there is a pushd/popd command in nix-prefetch-git that
outputs the directory name, breaking the structure of the result JSON.
We suppressed it with `>/dev/null`.
Passingly fixes a mixuse of tab and spaces.
This script needs to support being run both as part of a `fetchgit`
derivation and as a standalone, command-line tool.
The use of `$NIX_BUILD_TOP` only works when used in `fetchgit` but not when
invoked as a standalone tool. Instead we try to respect `$NETRC` so that
the command-line invocation behaves more like standard tools and the
`fetchgit` derivation can explicitly set `$NETRC` when `netrcPhase` is used
to avoid all ambiguity.
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.
Arguably, this is a bug in Nix's structuredAttrs: without
structuredAttrs, exportReferencesGraph with an empty path set would
still result in information being provided. With structuredAttrs, no
info is provided for an empty path set.
Nevertheless, we need to be able to build even if Nix has the bug, so
work around it by checking for an empty path set and handling it
explicitly.
Darwin does not actually require `*.dylib` extension, and some ports of
unix software may still simply compile and install these as `*.so` files.
Include `*.so` in the find in this case.
Co-authored-by: Artturi <Artturin@artturin.com>
Co-authored-by: toonn <toonn@toonn.io>
Rust is not yet able to target the n32 ABI on mips64.
Let's add `isMips64n32` to the `meta.badPlatforms` of all
derivations created by buildRustPackage.
I use this to automatically detect which packages on my system can
be built for n32 (almost all of them) and build those using n32, and
the few packages (mainly those that depend on boost or rust) that
can't for n64.
Rust is not yet able to target the n32 ABI on mips64.
Let's add `isMips64n32` to the `meta.badPlatforms` of all
derivations created by buildRustCrate.
I use this to automatically detect which packages on my system can
be built for n32 (almost all of them) and build those using n32, and
the few packages (mainly those that depend on boost or rust) that
can't for n64.
Before this commit, cc-wrapper/default.nix was using
`isGccArchSupported` to validate `-mtune=` values. This has two
problems:
- On x86, `-mtune=` can take the same values as `-march`, plus two
additional values `generic` and `intel` which are not valid for
`-march`.
- On ARM, `-mtune=` does not take the same values as `-march=`;
instead it takes the same values as `-mcpu`.
This commit fixes these two problems by adding a new
`isGccTuneSupported` function. For `isx86` this returns `true` for
the two special values and otherwise defers to `isGccArchSupported`.
This commit also adds support for `-mtune=` on Aarch64.
Unfortunately on Aarch64, Clang does not accept as wide a variety of
`-mtune=` values as Gcc does. In particular, Clang does not tune
for big.LITTLE mixed-model chips like the very popular RK3399, which
is targeted using `-march=cortex-a72.cortex-a53` in gcc.
To address this problem, this commit also adds a function
`findBestTuneApproximation` which can be used to map
clang-unsupported tunings like `cortex-a72.cortex-a53` to
less-precise tunings like `cortex-a53`.
The work which led to this commit arose because we now have
packages, like `crosvm`, which use *both* `clang` *and* `gcc`.
Previously I had been using `overrideAttrs` to set
`NIX_CFLAGS_COMPILE` on a package-by-package basis based on which
compiler that package used. Since we now have packages which use
*both* compilers, this strategy no longer works.
I briefly considered splitting `NIX_CFLAGS_COMPILE` into
`NIX_CFLAGS_COMPILE_GCC` and `NIX_CFLAGS_COMPILE_CLANG`, but since
`NIX_CFLAGS_COMPILE` is sort of a hack to begin with I figured that
adding the logic to `cc-wrapper` would be preferable.
