| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | | |
|
| | |\
| | |
| | | |
treewide: change various flags to allow x64 darwin to default to sdk 11.0 when ready
|
| | | |
| | |
| | |
| | |
| | | |
update code to not assume that x64 darwin must use sdk 10.12. After this
change it's possible to build a sdk 11 stdenv on darwin x64
|
| | | |
| | |
| | |
| | | |
After https://github.com/NixOS/nixpkgs/pull/322388, darwin.cctools is just Apple’s cctools again. The replacement for what the bootstrap tools wants is darwin.binutils-unwrapped.
|
| | | |
| | |
| | |
| | | |
GNU binutils is not preferred on Darwin, and newer versions have issues building. Make it an evaluation error to use it in the Darwin stdenv bootstrap.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
- Only link binaries that exist for stage 0 cctools and LLVM bintools;
- Drop cctools-llvm in favor of the updated darwin.binutils; and
- Update llvm-manages Python overrides (needed for newer versions of LLVM).
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |\|
| | |
| | |
| | |
| | | |
Conflicts:
- pkgs/os-specific/windows/mingw-w64/default.nix
|
| | |\ \
| | | |
| | | | |
cc-wrapper: add stack clash protection hardening flag
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Most Linux distributions are enabling this these days and it does
protect against real world vulnerabilities as demonstrated by
CVE-2018-16864 and CVE-2018-16865.
Fix #53753.
Information on llvm version support gleaned from
https://github.com/llvm/llvm-project/commit/6609892a2dcdd1a4f6adefe191b55524861f020c
https://github.com/llvm/llvm-project/commit/68e07da3e5d5175e24caa309e2b13cb333365c8c
https://github.com/llvm/llvm-project/commit/092507a730fa4fad6dbe544cd139cfb7e8179aa4
Information on gcc version support a lot harder to gather,
but both 32bit and 64bit arm do appear to be supported
based on the test suite.
|
| | |\ \ \
| | |/ /
| |/| | |
stdenv: log hooks as they run (take II)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A second take at eb28e5e72ef9, which was reverted for the extra logging
during the internals of `nix-shell -p`. This commit does the same
logging, but to $NIX_LOG_FD instead, which is echoed during any normal
build, but not during the internals of `nix-shell -p`.
[1]: eb28e5e72ef912629ded3e265f7344ca21d115b9
|
| | |\ \ \
| | | | |
| | | | | |
Annotate substituteStream deprecation warning
|
| | | |/ /
| | | |
| | | |
| | | | |
This adds the derivation name to the warning to make debugging easier.
|
| | |_|/
|/| |
| | |
| | |
| | | |
I've had better luck creating statically-linked binaries that work than
dynamically-linked ones, so this is needed quite practically.
|
| |\ \ \
| | | |
| | | | |
check-meta: fix instructions
|
| | | | | |
|
| | |/ /
| | |
| | |
| | | |
Corrections to 17718ac2552873bc9b6bbeb0c5b9469284a5d03b
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I realized what rhelmot did in 61202561d92cf1cd74532fcbd8b9d6662c5bc57b
(specify what packages just need `stdenvNoLibc`) is definitely the right
approach for this, and adjusted NetBSD and OpenBSD to likewise use it.
With that change, we don't need these confusing and ugly `*bsdCross`
package sets at all!
We can get rid of a lot more libc-related `*Cross`, and I will do so
soon, but this is the first step.
(adapted from commit 51f1ecaa59a3b7c182b24e71a3176c83d6cd601e)
|
| | | |
| | |
| | |
| | |
| | |
| | | |
It rebuilt stdenv on *-darwin; we can't do that in nixpkgs master.
This reverts commit 2f20501c5f188ab0c4c430519ce77bc6b988202b, reversing
changes made to fd469c24af2e16aad2c2b4fc90fc8c74af36e773.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For a long time, we've had `crossLibcStdenv`, `*Cross` libc attributes,
and `*bsdCross` pre-libc package sets. This was always bad because
having "cross" things is "not declarative": the naming doesn't reflect
what packages *need* but rather how we *provide* something. This is
ugly, and creates needless friction between cross and native building.
Now, almost all of these `*Cross` attributes are gone: just these are
kept:
- Glibc's and Musl's are kept, because those packages are widely used
and I didn't want to risk changing the native builds of those at this
time.
- generic `libcCross`, `theadsCross`, and friends, because these relate
to the convolulted GCC bootstrap which still needs to be redone.
The BSD and obscure Linux or freestnanding libcs have conversely all
been made to use a new `stdenvNoLibc`, which is like the old
`crossLibcStdenv` except:
1. It usable for native and cross alike
2. It named according to what it *is* ("a standard environment without
libc but with a C compiler"), rather than some non-compositional
jargon ("the stdenv used for building libc when cross compiling",
yuck).
I should have done this change long ago, but I was stymied because of
"infinite recursions". The problem was that in too many cases we are
overriding `stdenv` to *remove* things we don't need, and this risks
cyles since those more minimal stdenvs are used to build things in the
more maximal stdenvs.
The solution is to pass `stage.nix` `stdenvNoCC`, so we can override to
*build up* rather than *tear down*. For now, the full `stdenv` is also
passed, so I don't need to change the native bootstraps, but I can see
this changing as we make things more uniform and clean those up.
Finally, the BSDs also had to be cleaned up, since they have a few
pre-libc dependencies, demanding a systematic approach. I realized what
rhelmot did in 61202561d92cf1cd74532fcbd8b9d6662c5bc57b (specify what
packages just need `stdenvNoLibc`) is definitely the right approach for
this, and adjusted NetBSD and OpenBSD to likewise use it.
|
| |\ \
| |/
|/|
| |
| | |
raboof/check-meta-fix-allow-predicate-instructions
check-meta: fix 'predicate' instructions
|
| | |
| |
| |
| |
| |
| | |
In the code examples for using `allowUnfreePredicate` and
`allowNonSourcePredicate`, we use `lib.getName` (which removes
the version) and not the local `getName` (which keeps the version).
|
| |\ \ |
|
| | |\ \ |
|
| | | |\ \
| | | | |
| | | | | |
config.replaceCrossStdenv: add
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Example with `clangUseLLVM` which is the default when using `useLLVM`
```nix
config.replaceCrossStdenv = { buildPackages, baseStdenv }:
if baseStdenv.targetPlatform.useLLVM or false
then (buildPackages.stdenvAdapters.overrideCC baseStdenv buildPackages.llvmPackages_16.clangUseLLVM)
else baseStdenv;
```
The conditional necessary, otherwise the other sets(such as `pkgsCross.aarch64-multiplatform.llvmPackages`)
without `useLLVM` will use the stdenv without the necessary conditions to avoid infinite
recursion because of [targetLlvmLibraries](https://github.com/NixOS/nixpkgs/blob/644b234e1c17aad539c03ac8020f831e20241d50/pkgs/development/compilers/llvm/16/default.nix#L208)
usage.
[`replaceStdenv` is not used when cross-compiling](https://github.com/NixOS/nixpkgs/blob/d77bda728d5041c1294a68fb25c79e2d161f62b9/pkgs/stdenv/cross/default.nix#L12-L13)
`replaceStdenv` uses an additional stage to replace the stdenv to avoid
infinite recursion and other issues but that should not be necessary for cross.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Avoid building these packages more than once. Even though they require
linking to dylibs, they’re only used for running tests.
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
libiconv-darwin depends on Meson, which (indirectly) depends on
libiconv. When libiconv-darwin is set as libiconv, it will cause an
infinite recursion. Avoid the infinite recursion by using libiconvReal
in stage 1. Every stage after that can use libiconv-darwin.
|
| |/ / /
| | |
| | |
| | |
| | | |
Fixes: 7f3ca3e21a22 (stdenv: Fix handling of dependencies and hooks)
Fixes: #237458
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The cc and bintools wrapper contained ad hoc bootstrapping logic for
expand-response-params (which was callPackage-ed in a let binding). This
lead to the strange situation that the bootstrapping logic related to
expand-response-params is split between the wrapper derivations (where
it is duplicated) and the actual stdenv bootstrapping.
To clean this up, the wrappers simply should take expand-response-params
as an ordinary input: They need an adjacent expand-response-params (i.e.
one that runs on their host platform), but don't care about the how.
Providing this is only problematic during stdenv bootstrapping where we
have to pull it from the previous stage at times.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We don't need to artificially make sure that we can execute the wrapper
scripts on the build platform by using stdenv's shell (which comes from
buildPackages) since our cross infrastructure will get us the wrapper
from buildPackages. The upside of this change is that cross-compiled
wrappers (e.g. pkgsCross.aarch64-multiplatform.gcc) will actually work
when executed!
For bootstrapping this is also not a problem, since we have a long
build->build platform chain so runtimeShell is just as good as
stdenvNoCC.shell. We do fall back to old ways, though, by explicitly
using the bootstrap-tools shell in stage2, so the adjacent bash is only
used from stage4 onwards. This is unnecessary in principle (I'll try
removing this hack in the future), but ensures this change causes zero
rebuilds.
|
| |\| | | |
|
| | |\ \ \
| | | | |
| | | | | |
wrapCC, wrapBintools, stdenv: make Nix code a bit more consistent
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As of late, `final: prev: …` for overlays has become more prevalent in
newer code. This is also exhibited in some code (presumably added
recently) in stdenv. This change is not about any merits or demerits of
any naming convention, but rather aims to make the nomenclature in
stdenv bootstrapping consistent to lessen confusion.
I've chosen to stick to `self: super: …` convention because:
1. It is more common in the code as it stands.
2. Using `final: prev: …` makes the code more confusing, als it causes
`prev` to be in scope alongside `prevStage`. `prevStage` actually
bears no relation to `prev` even though their naming suggests it,
making it easy to confuse them (the former is the (final) package set
of the previous stage while the latter is just the `prev`/`super` of
the overlay “chaining” on a completely fresh package set, i.e. `prev`
doesn't even relate to the previous stage's `overrides` argument).
This change also corrects a naming error in stdenv/native which had no
effect, as the variables were unused.
|
| |\| | | | |
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This fixes using inputDerivation on derivations that are fixed-output.
Previously:
```
nix-repl> drv = runCommand "huh" { outputHash = "sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU="; outputHashAlgo = "sha256"; outputHashType = "flat"; } "touch $out"
nix-repl> drv.inputDerivation
«derivation /nix/store/d8mjs6cmmvsr1fv7psm6imis5pmh9bcs-huh.drv»
nix-repl> :b drv.inputDerivation
error: fixed output derivation 'huh' is not allowed to refer to other store paths.
You may need to use the 'unsafeDiscardReferences' derivation attribute, see the manual for more details.
```
Fixes: https://github.com/NixOS/nixpkgs/issues/304209
|
| |\| | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Nixpkgs tries to print a helpful message when it blocks unfree packages,
but the suggestion is subtly broken. The predicate only matches on the
package's name, but the suggestion includes the full name-version pair.
Fixed by formatting the message with the same function as the predicate.
This issue arises because check-meta defines its own local getName with
semantics divergent from lib.getName. The former includes the version,
the latter does not.
Example Before:
Alternatively you can configure a predicate to allow specific packages:
{ nixpkgs.config.allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [
"obsidian-1.5.12"
];
}
Example After:
Alternatively you can configure a predicate to allow specific packages:
{ nixpkgs.config.allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [
"obsidian"
];
}
Fixes #303116
|
| | | | |
| | | |
| | | |
| | | | |
See #300635. Maybe in time we'll have a better solution.
|
| |\| | | |
|
| | |\ \ \
| | | | |
| | | | | |
stdenv/check-meta: Make `checkValidity` only check validity
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
checkValidity has the responsibility to check if a derivation's attributes are valid.
Previously it also had the overloaded task of creating a subset of meta attributes:
- unfree
- broken
- unsupported
- insecure
Not only is this overloading strange, these attributes were only ever consumed by `commonMeta`.
This change makes checkValidity _only_ check for validity, and removes the creation of any meta attributes from `checkValidity` and moves them to `commonMeta`.
This is technically a breaking change but I don't expect any external nixpkgs consumers to rely on these implementation details.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
- update the hashes and tools needed to extract the bootstrap-tools archive
- unify the x64 and aarch64 unpack process
|
| |\| | | | |
|
