Adding pkgsStatic: a fully static overlay#48803
Conversation
GrahamcOfBorg
added
6.topic: stdenv
|
On Sun, 21 Oct 2018 15:43:08 -0700, Matthew Bauer ***@***.***> wrote:
###### Motivation for this change
This uses the cross compilation infrastructure to build a statically linked Musl-based package set. Some basic things seem to build okay... Working on getting things working as much as possible.
/cc @nh2 @dtzWill
You can view, comment on, or merge this pull request online at:
Big 👍 from me! At least in terms of the high-level goal.
Nothing against specifics 😁 but won't be able to look at them
properly for at least a few weeks :( so can't necessarily vouch
for them either hehe.
Apologies, will look through this eagerly as soon as I'm able!
:<3:
#48803
-- Commit Summary --
* Add crossOverlays
* Cleanup stdenv adapters
* Cleanup static overlay
* Use musl by default for pkgsStatic
-- File Changes --
M pkgs/stdenv/adapters.nix (10)
M pkgs/stdenv/cross/default.nix (17)
M pkgs/stdenv/darwin/default.nix (4)
M pkgs/stdenv/default.nix (4)
M pkgs/stdenv/linux/default.nix (2)
M pkgs/top-level/default.nix (4)
M pkgs/top-level/stage.nix (18)
A pkgs/top-level/static.nix (50)
-- Patch Links --
https://github.com/NixOS/nixpkgs/pull/48803.patch
https://github.com/NixOS/nixpkgs/pull/48803.diff
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#48803
Non-text part: text/html
|
|
Success on x86_64-linux (full log) Attempted: ncurses, zlib Partial log (click to expand)
|
|
Success on x86_64-darwin (full log) Attempted: ncurses, zlib Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: ncurses, zlib Partial log (click to expand)
|
|
@matthewbauer @dtzWill Are any of you at NixCon by any chance? |
|
No :(. Watching the stream, though!
…On Thu, 25 Oct 2018 13:14:05 +0000 (UTC), Niklas Hambüchen ***@***.***> wrote:
@matthewbauer @dtzWill Are any of you at NixCon by any chance?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#48803 (comment) part: text/html
|
|
Nope but @Ericson2314 should be |
|
Actually I won't be :(. I was too slow, and no tdpace left. |
|
Maybe next year I'll finally learn not to procrastinate. |
There was a problem hiding this comment.
Can use lib.withFeature for this
GrahamcOfBorg
added
the
2.status: merge conflict
matthewbauer
force-pushed
the
crossOverlays
branch
from
5befec5 to
f348ed7
Compare
GrahamcOfBorg
removed
the
2.status: merge conflict
|
Success on aarch64-linux (full log) Attempted: ncurses, zlib Partial log (click to expand)
|
|
Success on x86_64-darwin (full log) Attempted: ncurses, zlib Partial log (click to expand)
|
|
@GrahamcOfBorg build pkgsStatic.hello |
|
Success on x86_64-linux (full log) Attempted: ncurses, zlib Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: pkgsStatic.hello Partial log (click to expand)
|
|
Success on x86_64-darwin (full log) Attempted: pkgsStatic.hello Partial log (click to expand)
|
|
Success on x86_64-linux (full log) Attempted: pkgsStatic.hello Partial log (click to expand)
|
|
Success on x86_64-linux (full log) Attempted: ncurses, zlib Partial log (click to expand)
|
|
Success on x86_64-darwin (full log) Attempted: ncurses, zlib Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: ncurses, zlib Partial log (click to expand)
|
matthewbauer
changed the title
GrahamcOfBorg
added
the
2.status: merge conflict
matthewbauer
force-pushed
the
crossOverlays
branch
3 times, most recently
from
a0e0d77 to
51ddaf2
Compare
GrahamcOfBorg
removed
the
2.status: merge conflict
matthewbauer
force-pushed
the
crossOverlays
branch
from
51ddaf2 to
5e15b96
Compare
These aren’t needed with dontDisableStatic
crossOverlays only apply to the packages being built, not the build packages. It is useful when you don’t care what is used to build your packages, just what is being built. The idea relies heavily on the cross compiling infrastructure. Using this implies that we need to create a cross stdenv.
Nixpkgs is meant to link everything dynamically. We don’t want to expose static packages at the top level. If some package needs statically built binaries, it should use a custom override.
- makeStaticBinaries don’t work on Darwin (no stable ABI!) - Need to make sure NIX_CFLAGS_LINK appends - isStatic is not used anymore
The conditional was incorrect - postInstall script should only hsppen when enableShared = true.
This is kind of a mess, but basically: - static=true, shared=true means to build statically but move it to the static output - static=true, shared=false means to build statically and leave it in the main output - static=false, shared=true means to not build static at all Confusingly, the old default was static=true, shared=true even though static=false? Still can’t figure out what was meant by that.
when enableShared = false, we set --without-shared flag.
matthewbauer
force-pushed
the
crossOverlays
branch
from
5e15b96 to
b321ee9
Compare
Adds the static overlay that can be used to build Nixpkgs statically. Can be used like: nix build pkgsStatic.hello Not all packages build, as some rely on dynamic linking.
matthewbauer
force-pushed
the
crossOverlays
branch
from
b321ee9 to
6d90a8b
Compare
| overlays ? [] | ||
|
|
||
| , # List of overlays to apply to target packages only. | ||
| crossOverlays ? [] |
There was a problem hiding this comment.
This looks like a great improvement. As @Ericson2314 mentioned, this brings us much closer to build and host terminology. So what about changing this to hostOverlays, because then it can be applied to non-cross as well.
There was a problem hiding this comment.
With non cross, the build and host packages are the same, so it's not possible to just override in one case. crossOverrides actually will turn on cross if no crossSystem (to be renamed :)) was given to make things work.
There was a problem hiding this comment.
One reason that crossOverlays makes sense is that you will be using the "cross" stdenv here. This could be a little surprising, for instance, if you use crossOverlays on macOS, you will get CC=gcc instead of CC=clang.
There was a problem hiding this comment.
Yeah we should add LLVM-based cross. That is the easier part of iOS host-is-darwin cross, which is context in which I last worked on that. (i.e. I should have been worked on the lower hanging fruit but didn't.)
There was a problem hiding this comment.
@matthewbauer so that's the host or run CC, right? So why not hostOverlays or runOverlays? I'd say "cross" is a property of the entire package set: was it cross-compiled? yes or no, boolean. When describing which architecture some variable applies to, it should be build or host/run, because that is precise.
Now I might be entirely wrong about this, but this, crossOverlays, seems very similar to the way in which I accidentally wrote pkgs.extend to be a bit broken.
I'm trying to do something at the edge of my understanding of Nixpkgs internals here on a limited time budget. My initial goal was to achieve greater consistency, mainly between the Nixpkgs function and NixOS, so that it will be as simple as possible to understand the interface and work with it. I hope that a new-ish perspective is useful; if not, I should focus on other things.
There was a problem hiding this comment.
@Ericson2314 I seem to have lost the original conversation - but I think there is a way to disable the Clang dependency in cctools. You just have to define DISABLE_CLANG_AS here:
The builtin assembler should work fine then.
There was a problem hiding this comment.
@robeth That looks like okay logic. We definitely want to unify the build, host, target & local, cross, eventually. But I still am thinking crossOverlays is good here because it mirrors crossSystem. Right now, this is how I see it-
- {build,host,target}Platform - used internally in Nixpkgs as the "immediate" values of build, host, target. These are given to you, not set directly. Sliding windows algorithm handles the details...
- {local,cross}System - external arguments of Nixpkgs describing where you are and where you want to go. This is what you want to set to get from point a to point b.
If cross-compiling is a graph, then each node is a set of packages. We activate a kind of greedy pathfinding algorithm in moving from localSystem to crossSystem. Outside of Nixpkgs, we shouldn't care about the exact path that is taken, just that we end up with a package built by "localSystem", for "crossSystem". In the same way, when you set "crossOverlays", you are saying to give me a package set that is statically built, but using my localSystem as is.
|
Since this change, I get an error about passing an unknown crossOverlays argument to stdenv when using a custom stdenv. 2ee9522a6c76e28949b6237928d2cc74fb9edfc2 seems to fix it fine as far as I can tell, similar to what was done to the other stdenvs. Does this seem right? |
|
Thanks! I forgot to do some of the extra stdenv's. We could also just use |
| if stdenv.hostPlatform.isDarwin | ||
| then throw "Cannot build fully static binaries on Darwin/macOS" | ||
| else stdenv.mkDerivation (args // { | ||
| NIX_CFLAGS_LINK = toString (args.NIX_CFLAGS_LINK or "") + "-static"; |
There was a problem hiding this comment.
Yeah probably. The original version left out the space so I just left it as is
|
I've been playing with pkgsStatic today, I tried to build something which eventually required `meson` and then I hit this:
$ nix build nixpkgs.pkgsStatic.surf --show-trace
error: while evaluating the attribute 'buildInputs' of the derivation 'surf-2.0-x86_64-unknown-linux-musl' at /home/jb55/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:187:11:
while evaluating the attribute 'buildInputs' of the derivation 'webkitgtk-2.22.6-x86_64-unknown-linux-musl' at /home/jb55/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:187:11:
while evaluating the attribute 'nativeBuildInputs' of the derivation 'gst-plugins-base-1.14.4-x86_64-unknown-linux-musl' at /home/jb55/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:187:11:
while evaluating the attribute 'out.outPath' at /home/jb55/nixpkgs/lib/customisation.nix:142:13:
while evaluating the attribute 'crossFile' of the derivation 'meson-0.49.0-x86_64-unknown-linux-musl' at /home/jb55/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:187:11:
while evaluating the attribute 'text' of the derivation 'cross-file.conf' at /home/jb55/nixpkgs/pkgs/build-support/trivial-builders.nix:7:14:
while evaluating the attribute 'stdenv.targetPlatform.parsed.kernel.name' at /home/jb55/nixpkgs/pkgs/stdenv/booter.nix:111:5:
attribute 'targetPlatform' missing, at /home/jb55/nixpkgs/pkgs/development/tools/build-managers/meson/default.nix:70:17
it seems to be complaining about this section in meson's derivation:
[host_machine]
system = '${targetPackages.stdenv.targetPlatform.parsed.kernel.name}'
cpu_family = '${targetPackages.stdenv.targetPlatform.parsed.cpu.family}'
cpu = '${targetPackages.stdenv.targetPlatform.parsed.cpu.name}'
endian = ${if targetPackages.stdenv.targetPlatform.isLittleEndian then "'little'" else "'big'"}
For some reason stdenv.targetPlatform is missing.
Any ideas? I'm not too familiar with the cross compilation
infrastructure to fix this.
Cheers,
Will
|
|
Yeah meson looks to be broken right now. |
10 participants
Motivation for this change
This uses the cross compilation infrastructure to build a statically linked Musl-based package set. Some basic things seem to build okay... Working on getting things working as much as possible.
You can access them from the pkgsStatic attribute set. Basic things like pkgsStatic.hello seem to work okay.
As part of the implementation this adds a new type of overlay called "crossOverlays". These are similar to ordinary overlays except for one critical difference. They only apply to the /target/ package set. To accomplish this, we use the cross stdenv to clearly separate out build, host, and target.
In addition, I have added a custom "static" overlay that will enable static by modifying the stdenv and modifying other packages as necessary. Additional packages can be enabled later on here.
/cc @nh2 @dtzWill