Commit graph

1951 commits

Author SHA1 Message Date
Niklas Hambüchen 3ac484ef83
Merge pull request #129328 from nh2/manual-fix-hardening-flags-sections
manual: hardening: Fix disabled flags prose being in previous section
2021-07-05 23:11:22 +02:00
Niklas Hambüchen ac36a0f9eb manual: hardening: Fix disabled flags prose being in previous section
This confused the hell out of me, as I didn't spot the

> The following flags are disabled by default ...

when reading about `pie`, because that sentence was hidden in the
previous hardening flag's section.

Also explain that `pie` hardening is on by default on musl.
2021-07-05 16:32:55 +02:00
Sandro d871186cdf
Merge pull request #108102 from matthewbauer/bash-version-check
stdenv/setup.sh: Add version check to setup script
2021-06-24 13:06:46 +02:00
Matthew Bauer 8fa084dc0f stdenv/setup.sh: Add version check to setup script
Only bash 4+ works in setup.sh. To make sure this is obvious, we can
check BASH_VERSINFO to get the major version number of Bash.

While Bash 3 is pretty rare, it still comes stock in macOS.

We *could* provide a warning here for non-Bash shells, but it’s not
always clear whether they will work or not. Zsh should have no trouble
while busybox sh, fish, or any others. There’s no great way to detect
what feature set the shell supports.

Fixes #71625
2021-06-23 01:32:58 -05:00
Jan Tojnar e3dfa79441
Merge branch 'staging-next' into staging
Regenerated pkgs/servers/x11/xorg/default.nix to resolve the conflict.
2021-06-16 19:59:05 +02:00
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
Alyssa Ross b0b5ef7286 stdenv: introduce dontAddStaticConfigureFlags
With removeUnknownConfigureFlags, it's impossible to express a package
that needs --enable-static, but will not accept --disable-shared,
without overriding the result of removeUnknownConfigureFlags _again_
in pkgs/top-level/static.nix.

It would be much better (and more in line with the rest of Nixpkgs) if
we encoded changes needed for static builds in package definitions
themselves, rather than in an ever-expanding list in static.nix.  This
is especially true when doing it in static.nix is going to require
multiple overrides to express what could be expressed with stdenv
options.

So as a step in that direction, and to fix the problem described
above, here I replace removeUnknownConfigureFlags with a new stdenv
option, dontAddStaticConfigureFlags.  With this mechanism, a package
that needs one but not both of the flags just needs to set
dontAddStaticConfigureFlags and then set up configureFlags manually
based on stdenv.hostPlatform.isStatic.
2021-06-11 14:16:05 -07: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