summary refs log tree commit diff
path: root/pkgs/stdenv
Commit message (Collapse)AuthorAge
...
| * | bootstrap-tools: Add bootstrapFiles argumenttoonn2021-06-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was having a hard time testing new bootstrapFiles because `make-bootstrap-tools.nix` imports `pkgspath` but does not pass anything but the current system. This is merely for convenience and I'm not entirely certain it's a sensible thing to do, maybe generating new bootstrapFiles while overriding the current bootstrapFiles isn't something you're supposed to do?
| * | bootstrap-tools: Fix xnu python3 patchtoonn2021-06-05
| | | | | | | | | | | | | | | This patch only affects the xnu included in the bootstrap-tools to avoid a stdenv rebuild.
* | | stdenv/native: fix bintools importJonathan Ringer2021-06-07
| | |
* | | Merge pull request #125494 from siraben/remove-stdenv-libSandro2021-06-05
|\ \ \
| * | | stdenv: remove libBen Siraphob2021-06-03
| |/ /
* / / stdenv.darwin: nixpkgs-fmthappysalada2021-06-02
|/ /
* | darwin/make-bootstrap-tools: move "lib" from install name to rpathAndrew Childs2021-05-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The rpath structure for the bootstrap tools was reworked to minimize the amount of rewriting required on unpack, but the test was not updated to match the different structure. Additionally [1] builds that use the bootstrap version of libc++ cannot find libc++abi if the reference includes the "lib" component (ie, libc++ refers to libc++abi with @rpath/lib/libc++abi.dylib). [1] https://logs.nix.samueldr.com/nix-darwin/2021-05-18#4993282 Test failure observed on Hydra: https://hydra.nixos.org/build/143130126
* | stdenv/darwin: add bootstrap tools for aarch64-darwinAndrew Childs2021-05-18
| | | | | | | | Taken from PR #12355; other parts are still being discussed.
* | stdenv/darwin: Apple Silicon supportAndrew Childs2021-05-17
| |
* | stdenv/darwin: bootstrap tools for Apple SiliconAndrew Childs2021-05-17
| |
* | darwin cross: include CoreFoundation in stdenvAndrew Childs2021-05-17
| |
* | treewide: All the linker to be chosen independentlyJohn Ericson2021-05-14
| | | | | | | | | | | | | | | | This will begin the process of breaking up the `useLLVM` monolith. That is good in general, but I hope will be good for NetBSD and Darwin in particular. Co-authored-by: sterni <sternenseemann@systemli.org>
* | darwin packages: Get ready for crossJohn Ericson2021-05-11
| | | | | | | | | | | | | | | | If things build fine with `stdenvNoCC`, let them use that. If tools might be prefixed, prepare for that, either by directly splicing or just using the env vars provided by the wrapper setup-hooks. Co-authored-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
* | glibc: Use `pname` and `version`John Ericson2021-05-10
| |
* | Merge remote-tracking branch 'upstream/staging-next' into stagingJohn Ericson2021-05-06
|\ \
| * | treewide: Do a number of no-op cleanups for cross and darwinJohn Ericson2021-05-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I am taking the non-invasive parts of #110914 to hopefully help out with #111988. In particular: - Use `lib.makeScopeWithSplicing` to make the `darwin` package set have a proper `callPackage`. - Adjust Darwin `stdenv`'s overlays keeping things from the previous stage to not stick around too much. - Expose `binutilsNoLibc` / `darwin.binutilsNoLibc` to hopefully get us closer to a unified LLVM and GCC bootstrap.
* | | llvmPackages: Multuple outputs for everythtingAndrew Childs2021-04-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also begin to start work on cross compilation, though that will have to be finished later. The patches are based on the first version of https://reviews.llvm.org/D99484. It's very annoying to do the back-porting but the review has uncovered nothing super major so I'm fine sticking with what I've got. Beyond making the outputs work, I also strove to re-sync the packages, as they have been drifting pointlessly apart for some time. ---- Other misc notes, highly incomplete - lvm-config-native and llvm-config are put in `dev` because they are tools just for build time. - Clang no longer has an lld dep. That was introduced in db29857eb391ed002046090851a44c452b80bdbd, but if clang needs help finding lld when it is used we should just pass it flags / put in the resource dir. Providing it at build time increases critical path length for no good reason. ---- A note on `nativeCC`: `stdenv` takes tools from the previous stage, so: 1. `pkgsBuildBuild`: `(?1, x, x)` 2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)` while: 1. `pkgsBuildBuild`: `(?1, x, x)` 2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)` 3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
* | | Merge staging-next into staginggithub-actions[bot]2021-04-28
|\| |
| * | Merge pull request #120993 from regnat/easy-caJohn Ericson2021-04-28
| |\ \ | | | | | | | | Make the bootsrap respect the contentAddressedByDefault setting
| | * | Also make the bootstrap tools generation CAregnat2021-04-28
| | | | | | | | | | | | | | | | (And fix an ofborg eval error btw)
| | * | Make the bootsrap respect the contentAddressedByDefault settingregnat2021-04-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch every `derivation` call in the bootsrap process to add it a conditional `__contentAddressed` parameter. That way, passing `contentAddressedByDefault` means that the entire build closure of a system can be content addressed
* | | | Merge staging-next into staginggithub-actions[bot]2021-04-27
|\| | |
| * | | pkgs/stdenv/make-derivation: move hostSuffix before the versionsternenseemann2021-04-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adding the hostSuffix to the end of the derivation's name is problematic since some stuff, including user facing programs like nix-env rely on the behavior of parseDrvName instead of pname and version. builtins.parseDrvName currently thinks that the cross compilation target added via hostSuffix is part of the version. This has the practical consequence for example that nix-env would think a cross compiled derivation would be an updated version of a native derivation of the same package and version — breaking user's profiles. We can easily prevent this by moving the hostSuffix in between pname and version. In case name is passed to mkDerivation this is of course not possible and we are forced to fall back to the old behavior. This change could serve as a replacement for the migitation we introduced with the -static appendix to pname in order to avoid confusion between nix and nixStatic as outlined in the comment added with this commit.
* | | | Merge staging-next into staginggithub-actions[bot]2021-04-26
|\| | |
| * | | Merge pull request #120316 from regnat/easy-caEelco Dolstra2021-04-26
| |\| | | | | | | | | | Make it easy to try out content-addressed derivations
| | * | Remove the NIXPKGS_CA_BY_DEFAULT env variableregnat2021-04-26
| | | | | | | | | | | | | | | | Not really needed, and not desired either
| | * | Make it easy to build everything as content-addressedregnat2021-04-23
| | | | | | | | | | | | | | | | | | | | | | | | Add a config field `contentAddressedByDefault` and an associated environment variable `NIXPKGS_CA_BY_DEFAULT` to make every nixpkgs derivation content-addressed by default
| | * | Allow easily marking a derivation as content-addressedregnat2021-04-23
| | | |
| * | | stdenv: support mainProgram in metaAna Hobden2021-04-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support `mainProgram` as an attribute of `meta` for packages. This is an attribute used by [`nix run`](https://nixos.org/manual/nix/unstable/command-ref/new-cli/nix3-run.html#description) to customize the main program of a package. For example, `pkgs.neovim` provides a `/bin/nvim` executable which users would (almost certainly) prefer `nix run` to execute instead of a non-existing `/bin/neovim`. Signed-off-by: Ana Hobden <operator@hoverbear.org>
* | | | Merge pull request #112928 from baloo/baloo/gcc/reproducibleArnout Engelen2021-04-26
|\ \ \ \ | | | | | | | | | | stdenv: provide a deterministically built gcc
| * | | | stdenv: provide a deterministically built gccArthur Gautier2021-03-01
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Arthur Gautier <baloo@superbaloo.net>
* | | | | stdenvNoCC: Fix `hasCC` attr during cross, remove `noCC`John Ericson2021-04-23
| |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | `hasCC` was getting overridden in the cross bootstrapping (for GHCJS), which preventing the default logic from re-triggering for `stdenvNoCC`. Also remove `stdenv.noCC` which is obseleted by `stdenv.hasCC`.
* | | | Merge master into staging-nextgithub-actions[bot]2021-04-22
|\ \ \ \ | | |/ / | |/| |
| * | | Merge pull request #120080 from Radvendii/cc-wrapper-libJohn Ericson2021-04-22
| |\ \ \ | | | | | | | | | | stdenv/{native,nix}: add lib to cc-wrapper args
| | * | | stdenv/{native,nix}: add lib to cc-wrapper argsTaeer Bar-Yam2021-04-21
| | | | |
* | | | | Merge master into staging-nextgithub-actions[bot]2021-04-19
|\| | | |
| * | | | stdenv.isBSD: reinitAlyssa Ross2021-04-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was removed in e29b0da9c7492732e0dc5730c3da754baa57a1a2, because it was felt it was ambiguous whether isBSD should remove Darwin. I think it should be reintroduced. Packages sometimes have their own concepts of "is BSD" e.g. Lua, and these almost never include Darwin, so let's keep Darwin excluded. Without a way to say "is this BSD", one has to list all flavours of BSD seperately, even though fundamentally they're still extremely similar. I don't want to have to write the following! stdenv.isFreeBSD || stdenv.isNetBSD || stdenv.isOpenBSD || stdenv.isDragonFlyBSD Additionally, we've had stdenv.hostPlatform.isBSD this whole time, and it hasn't hurt anything.
* | | | | Merge master into staging-nextgithub-actions[bot]2021-04-15
|\| | | |
| * | | | stdenv/freebsd/cc: make overrideable fixing nixpkgs evalsternenseemann2021-04-15
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | stdenv.cc didn't have an override attribute on FreeBSD previously, breaking evaluation of all-packages.nix consequently. Resolves #119075.
* | | | Merge branch 'staging' into staging-nextVladimír Čunát2021-04-14
|\ \ \ \ | |/ / / |/| | | | | | | A few conflicts but relatively clear ones (I think).
| * | | Merge remote-tracking branch 'upstream/staging-next' into down-integrate-stagingLuke Granger-Brown2021-04-12
| |\ \ \
| * | | | darwin: move deployment target and sdk version to platform configAndrew Childs2021-03-26
| | | | |
* | | | | stdenv/make-derivation: add -static to name if building staticallysternenseemann2021-04-13
| | | | |
* | | | | stdenv/make-derivation: unify logic for name modificationssternenseemann2021-04-13
| |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | Unify the logic for constructing the name from pname and version and modifying the name in case a host suffix needs to appended. This allows us to modify the construction of name from pname and version without having to duplicate it in two places.
* | | | Merge pull request #116495 from r-burns/ppc64Sandro2021-04-12
|\ \ \ \ | |/ / / |/| | | lib/systems: remove powerpc64 elfv1 support
| * | | stdenv/bootstrap-tools: remove powerpc64 special caseRyan Burns2021-03-15
| |/ / | | | | | | | | | | | | Now that powerpc64 is always ELFv2, we can unconditionally use musl tools here.
* | | Merge master into staging-nextgithub-actions[bot]2021-03-24
|\ \ \
| * | | stdenv: Fix regression on ARM+static when enabling hardening (#115363)Samuel Dionne-Riel2021-03-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4e9dc46dea0ef8cf15c567fa863796bb23099d0b re-enabled hardening for Musl, which is good. Though static builds for ARM fail in various ways - cross armv7l static does not build - cross aarch64 static produces segfaulting dynamically linked binaries - native aarch64 static also produces segfaulting dynamically linked binaries It seems that for native x86_64-linux, static builds are fine though. This works around the issue by removing PIE from the hardening flags, keeping all other hardening flags. This is an improvement (I think) from before 4e9dc46d. Fixes #114953
* | | | Merge staging-next into staginggithub-actions[bot]2021-03-19
|\| | |
| * | | darwin/make-bootstrap-tools: avoid brotli dependencyRyan Burns2021-03-18
| | | | | | | | | | | | | | | | Needed as of e3d19670a0f6b012aac5e05b50951d8a991ba143