Conflicts:
- pkgs/development/python-modules/boto3-stubs/default.nix
- pkgs/development/python-modules/openllm-core/default.nix
Between 0.4.22 → 0.4.34 (a82245bd3d)
and 0.4.22 -> 0.4.41 (72c55ce6a6)
Does not build, not pre-merge either.
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.
