about summary refs log tree commit diff
path: root/pkgs/stdenv
AgeCommit message (Collapse)AuthorFilesLines
2024-06-18Clean up cross bootstrappingJohn Ericson2-21/+34
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.
2024-05-30Merge pull request #297987 from ↵Arnout Engelen1-4/+4
raboof/check-meta-fix-allow-predicate-instructions check-meta: fix 'predicate' instructions
2024-05-03Merge staging-next into staginggithub-actions[bot]1-37/+40
2024-05-03Merge master into staging-nextgithub-actions[bot]1-37/+40
2024-05-03Merge pull request #269461 from Artturin/addcrossreplaceArtturin1-37/+40
config.replaceCrossStdenv: add
2024-04-27libiconv: use libiconv-darwinRandy Eckenrode1-6/+6
2024-04-27darwin.stdenv: propagate atf and kyuaRandy Eckenrode1-12/+12
Avoid building these packages more than once. Even though they require linking to dylibs, they’re only used for running tests.
2024-04-27darwin.stdenv: avoid an infinite recursionRandy Eckenrode1-1/+4
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.
2024-04-19stdenv: fix missing dependencies in __sandboxProfile and __impureHostDepsDavid McFarland1-4/+7
Fixes: 7f3ca3e21a22 (stdenv: Fix handling of dependencies and hooks) Fixes: #237458
2024-04-19Merge branch 'master' into staging-nextVladimír Čunát2-33/+33
2024-04-18wrapCC, wrapBintools: move expand-response-params bootstrapping outsternenseemann2-24/+16
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.
2024-04-18wrapCC, wrapBintools: use runtimeShell instead of stdenv shellsternenseemann2-9/+17
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.
2024-04-18Merge master into staging-nextgithub-actions[bot]2-5/+5
2024-04-18Merge pull request #304033 from sternenseemann/wrapper-cleanupsJohn Ericson2-5/+5
wrapCC, wrapBintools, stdenv: make Nix code a bit more consistent
2024-04-15Merge master into staging-nextgithub-actions[bot]1-1/+7
2024-04-15stdenv: consistently use `self: super: …` for bootstrapping overlayssternenseemann2-5/+5
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.
2024-04-15stdenv: make inputDerivation never fixed-outputJade Lovelace1-1/+7
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
2024-04-13Merge master into staging-nextgithub-actions[bot]1-1/+1
2024-04-10stdenv/check-meta: Fix error message for disallowed unfree packagesDan Callahan1-1/+1
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
2024-04-10stdenv: avoid setuid issuesVladimír Čunát1-1/+2
See #300635. Maybe in time we'll have a better solution.
2024-04-09Merge branch 'staging-next' into stagingWeijia Wang1-16/+21
2024-04-07stdenv.darwin: bootstrap darwin using updated toolsannalee6-149/+53
- update the hashes and tools needed to extract the bootstrap-tools archive - unify the x64 and aarch64 unpack process
2024-04-07Merge pull request #297353 from adisbladis/check-meta-validity-onlyadisbladis1-16/+21
stdenv/check-meta: Make `checkValidity` only check validity
2024-04-05Merge staging-next into staginggithub-actions[bot]2-22/+0
2024-04-04Merge pull request #297074 from lolbinarycat/tarfixRyan Lahfa1-2/+2
stdenv: pass --mode=+w to tar, ensuring extraction is possible
2024-04-04pkgs/top-level/release.nix: drop unused `dist` targetsSergei Trofimovich2-22/+0
The PR https://github.com/NixOS/nixpkgs/pull/284090 exposed `build` target directly on hydra. We are using it now in https://github.com/NixOS/nixpkgs/tree/master/maintainers/scripts/bootstrap-files to generate bootstrap tarballs on `linux` and `darwin`. `dist` was not very useful as it was a bit hard to link back to hydra jobs that build it. Let's just drop it.
2024-04-03stdenv/check-meta: Make `checkValidity` only check validityadisbladis1-16/+21
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.
2024-04-03Merge staging-next into staginggithub-actions[bot]1-84/+71
2024-04-01freshBootstrapTools.{build,test}: group tools togetherannalee1-39/+32
2024-04-01freshBootstrapTools.{build,test}: allow exes with libs unpackannalee1-33/+17
2024-04-01freshBootstrapTools.{build,test}: fix as script. test all executablesannalee1-12/+22
as is a wrapper around clang and the path to bash and clang need to be updated when unpacked run all executables in bin get run in the test
2024-03-30Merge staging-next into staginggithub-actions[bot]1-26/+1
2024-03-30Merge master into staging-nextgithub-actions[bot]1-26/+1
2024-03-30Revert "stdenv: add meta.repository field"K9001-27/+1
This reverts commit 7e1443abbba99e9dac29ce2ad01c1c4e4fb66070.
2024-03-30Revert "stdenv/check-meta: Don't create new environments when computing ↵K9001-15/+16
meta.repository" This reverts commit f8b091d53fdb339a9489551e21ceb4bad84c79e9.
2024-03-30Merge staging-next into staginggithub-actions[bot]1-26/+37
2024-03-30Merge master into staging-nextgithub-actions[bot]1-26/+37
2024-03-30stdenv/check-meta: don't infrec on unsupported platformsK9001-3/+3
2024-03-30Merge pull request #300177 from adisbladis/meta-repository-perf-fixupsadisbladis1-20/+27
stdenv/check-meta: Fix performance regressions introduced in #294347
2024-03-30stdenv/check-meta: Inherit remaining lib access into scopeadisbladis1-4/+12
Hopefully this will result in people not adding new `lib.xxx` to check-meta.nix.
2024-03-30stdenv/check-meta: Don't create new environments when computing meta.repositoryadisbladis1-16/+15
2024-03-30Merge pull request #297350 from adisbladis/commonmeta-output-listadisbladis1-4/+8
stdenv/check-meta: Remove outputsToInstall list concat from common meta
2024-03-30Merge staging-next into staginggithub-actions[bot]1-1/+27
2024-03-30Merge master into staging-nextgithub-actions[bot]1-1/+27
2024-03-29Merge pull request #294347 from lolbinarycat/meta.repositorya-n-n-a-l-e-e1-1/+27
stdenv: add meta.repository field
2024-03-29stdenv: add meta.repository fieldbinarycat1-1/+27
2024-03-29Merge pull request #300032 from NixOS/revert-295558-darwin-bootstrap-updatea-n-n-a-l-e-e6-53/+149
Revert "stdenv.darwin: bootstrap darwin using updated tools"
2024-03-29Revert "stdenv.darwin: bootstrap darwin using updated tools"a-n-n-a-l-e-e6-53/+149
2024-03-29darwin.stdenv: add sdkRoot to extraNativeBuildInputsRandy Eckenrode1-5/+37
Setting the SDK root by default allows `overrideSDK` to correctly set the SDK version when using a different SDK. It also allows the correct SDK version to be set when using an older deployment target. Not setting the correct SDK version can result in unexpected behavior at runtime. Examples: * Automatic dark mode switching requires linking against an SDK version of 10.14 or newer. With the current behavior, the only way to do this is by using a 10.14+ deployment target even when the application supports older platforms when build with a newer SDK. * MetalD3D checks that the system version is at least 14.0. The API it uses returns a compatibility version when the the SDK is older than 11.0, which causes it to display an error and terminate the application even when even when its requirements are all met.
2024-03-29overrideSDK: support all deps attributesRandy Eckenrode2-119/+448
This is effectively a rewrite of `overrideSDK`. It was required because `wrapGAppsHook` propagates `depsTargetTarget` with the expectation that it will effectively be `buildInputs` when the hook is itself used as a `nativeBuildInput`. This propagates Gtk, which itself propagates the default Dariwn SDK, making it effectively impossible to override the SDK when a package depends on Gtk and uses `wrapGAppsHook`. This rewrite implements the following improvements: * Cross-compilation should be supported correctly (untested); * Supports public and private frameworks; * Supports SDK `libs`; * Remaps instead of replacing extra (native) build inputs in the stdenv; * Updates any Darwin framework references in `nix-support`; and * It updates `xcodebuild` regardless of which input its in. The implementation avoids recursion for performance reasons. Instead, it enumerates transitive dependencies and walks the list from the leaf packages backwards to the parent packages.