Commit graph

1945 commits

Author SHA1 Message Date
Daiderd Jordan 40ffedfb38
darwin: expose bootstrapLlvmVersion as argument in the stdenv
This enables the bootstrap stdenv test to specify the actual llvm
of the newly generated build instread of assuming it's the same version
as the current stdenv.
2021-06-13 17:32:06 +02:00
Daiderd Jordan bdffd0b276
Merge pull request #121055 from toonn/bootstrap-tools-bump
darwin bootstrap-tools bump LLVM to 11
2021-06-09 08:23:20 +02:00
Jonathan Ringer 04bdefc4b8 stdenv/native: fix bintools import 2021-06-07 11:26:15 +00:00
toonn c7b433acf9
bootstrap-tools: libclang-cpp already included
Changes to llvmPackages have caused the `libclang-cpp*.dylib` files to
be included in the `clang-unwrapped.lib` output. So we no longer need to
copy them from libclang.
2021-06-06 20:17:32 +02:00
toonn 336d82617f
bootstrap-tools: Patch TargetConditionals.h
`TargetConditionals.h` was missing several definitions, like
`TARGET_OS_TV` that are part of SDK 10.12 at least. And one that doesn't
seem to occur in any SDK afaict, `TARGET_OS_EMBEDDED_OTHER`.

I added the definitions from SDK 10.12 verbatim and defined
`TARGET_OS_EMBEDDED_OTHER` to be equal to `0`.

This is a modified version of a patch to avoid a stdenv rebuild.
2021-06-06 20:17:13 +02:00
toonn fa49e70c1b
bootstrap-tools: Include libclang-cpp.11.1.dylib too
We need to include the library with the version suffix because
`libclang-cpp.dylib` is just a symlink.
2021-06-05 19:56:53 +02:00
toonn d259fcc3e2
bootstrap-tools: Include libclang-cpp.dylib
Credits to @LnL7, this is based on commit
ae68f1c447d775e64d6e16a33f2affe591c419bf from PR #85151.
2021-06-05 19:56:53 +02:00
toonn 4a2698221b
bootstrap-tools: Update to LLVM 11 2021-06-05 19:56:53 +02:00
toonn 3b8782a806
bootstrap-tools: Add bootstrapFiles argument
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?
2021-06-05 19:56:53 +02:00
toonn 7da313e10a
bootstrap-tools: Fix xnu python3 patch
This patch only affects the xnu included in the bootstrap-tools to avoid
a stdenv rebuild.
2021-06-05 19:55:38 +02:00
Sandro c3f5d24b8d
Merge pull request #125494 from siraben/remove-stdenv-lib 2021-06-05 16:16:28 +02:00
Ben Siraphob d2c9f816e3 stdenv: remove lib 2021-06-03 19:50:15 +07:00
happysalada 1c1c7685d9 stdenv.darwin: nixpkgs-fmt 2021-06-02 19:03:48 +09:00
Andrew Childs 38207735f4 darwin/make-bootstrap-tools: move "lib" from install name to rpath
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
2021-05-24 15:04:39 +09:00
Andrew Childs 5d22db3c5e
stdenv/darwin: add bootstrap tools for aarch64-darwin
Taken from PR #12355; other parts are still being discussed.
2021-05-18 21:34:57 +02:00
Andrew Childs 768aae66ef stdenv/darwin: Apple Silicon support 2021-05-17 00:27:02 +09:00
Andrew Childs 3eacdfe24a stdenv/darwin: bootstrap tools for Apple Silicon 2021-05-17 00:27:02 +09:00
Andrew Childs a7bcb6b936 darwin cross: include CoreFoundation in stdenv 2021-05-17 00:27:01 +09:00
John Ericson 18c38f8aee treewide: All the linker to be chosen independently
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>
2021-05-14 21:29:51 +00:00
John Ericson 7bba32a069 darwin packages: Get ready for cross
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>
2021-05-11 16:07:01 -04:00
John Ericson 77e97ac4ca glibc: Use pname and version 2021-05-10 20:56:33 +00:00
John Ericson a3e54cb582 Merge remote-tracking branch 'upstream/staging-next' into staging 2021-05-06 15:48:25 -04:00
John Ericson 470640e7fe treewide: Do a number of no-op cleanups for cross and darwin
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.
2021-05-06 11:17:26 -04:00
Andrew Childs 7869d16545 llvmPackages: Multuple outputs for everythting
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
  db29857eb3, 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)`
2021-04-30 05:41:00 +00:00
github-actions[bot] 9cf0393c37
Merge staging-next into staging 2021-04-28 18:14:28 +00:00
John Ericson 50a11f4f43
Merge pull request #120993 from regnat/easy-ca
Make the bootsrap respect the contentAddressedByDefault setting
2021-04-28 11:27:59 -04:00
regnat 4105c06bf3 Also make the bootstrap tools generation CA
(And fix an ofborg eval error btw)
2021-04-28 12:46:43 +02:00
regnat 14f66d60a7 Make the bootsrap respect the contentAddressedByDefault setting
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
2021-04-28 10:25:49 +02:00
github-actions[bot] 489dda0090
Merge staging-next into staging 2021-04-27 00:15:12 +00:00
sternenseemann b0c26d2c40 pkgs/stdenv/make-derivation: move hostSuffix before the version
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.
2021-04-26 20:40:52 +02:00
github-actions[bot] f0290a5d27
Merge staging-next into staging 2021-04-26 18:14:28 +00:00
Eelco Dolstra 6b19be4124
Merge pull request #120316 from regnat/easy-ca
Make it easy to try out content-addressed derivations
2021-04-26 16:21:05 +02:00
regnat 559c5792ef Remove the NIXPKGS_CA_BY_DEFAULT env variable
Not really needed, and not desired either
2021-04-26 16:20:13 +02:00
Arnout Engelen 48c952c039
Merge pull request #112928 from baloo/baloo/gcc/reproducible
stdenv: provide a deterministically built gcc
2021-04-26 11:07:34 +02:00
Ana Hobden acfddd576e stdenv: support mainProgram in meta
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>
2021-04-25 21:19:49 -07:00
John Ericson f684c917a6 stdenvNoCC: Fix hasCC attr during cross, remove noCC
`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`.
2021-04-23 21:54:42 +00:00
regnat cc5b30c6ac Make it easy to build everything as content-addressed
Add a config field `contentAddressedByDefault` and an associated
environment variable `NIXPKGS_CA_BY_DEFAULT` to make every nixpkgs
derivation content-addressed by default
2021-04-23 10:54:38 +02:00
regnat 2f45625673 Allow easily marking a derivation as content-addressed 2021-04-23 10:49:10 +02:00
github-actions[bot] 8248f4db36
Merge master into staging-next 2021-04-22 06:05:51 +00:00
John Ericson fce51c8457
Merge pull request #120080 from Radvendii/cc-wrapper-lib
stdenv/{native,nix}: add lib to cc-wrapper args
2021-04-22 01:05:22 -04:00
Taeer Bar-Yam 0a8784d5db stdenv/{native,nix}: add lib to cc-wrapper args 2021-04-21 11:56:55 -04:00
github-actions[bot] 6ef7c23763
Merge master into staging-next 2021-04-19 18:11:51 +00:00
Alyssa Ross 730a9a04fa
stdenv.isBSD: reinit
This was removed in e29b0da9c7, 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.
2021-04-18 20:12:09 +00:00
github-actions[bot] 9c190d28df
Merge master into staging-next 2021-04-15 12:06:13 +00:00
sternenseemann 62ec3db017 stdenv/freebsd/cc: make overrideable fixing nixpkgs eval
stdenv.cc didn't have an override attribute on FreeBSD previously,
breaking evaluation of all-packages.nix consequently.

Resolves #119075.
2021-04-15 12:49:41 +02:00
Vladimír Čunát d2eb7a7887
Merge branch 'staging' into staging-next
A few conflicts but relatively clear ones (I think).
2021-04-14 10:08:25 +02:00
sternenseemann 851c0f1cb7 stdenv/make-derivation: add -static to name if building statically 2021-04-13 12:33:00 +02:00
sternenseemann fe0524cd7d stdenv/make-derivation: unify logic for name modifications
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.
2021-04-13 12:31:26 +02:00
Luke Granger-Brown 08b22e605b Merge remote-tracking branch 'upstream/staging-next' into down-integrate-staging 2021-04-12 18:49:01 +00:00
Sandro 9f198c1423
Merge pull request #116495 from r-burns/ppc64
lib/systems: remove powerpc64 elfv1 support
2021-04-12 16:44:14 +02:00