-
-
Notifications
You must be signed in to change notification settings - Fork 14.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding pkgsStatic: a fully static overlay #48803
Conversation
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. |
@@ -28,7 +29,7 @@ stdenv.mkDerivation rec { | |||
setOutputFlags = false; # some aren't supported | |||
|
|||
configureFlags = [ | |||
"--with-shared" | |||
(if enableShared then "--with-shared" else "--without-shared") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can use lib.withFeature
for this
5befec5
to
f348ed7
Compare
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)
|
a0e0d77
to
51ddaf2
Compare
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.
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.
b321ee9
to
6d90a8b
Compare
|
||
, # Allow a configuration attribute set to be passed in as an argument. | ||
config ? {} | ||
|
||
, # List of overlays layers used to extend Nixpkgs. | ||
overlays ? [] | ||
|
||
, # List of overlays to apply to target packages only. | ||
crossOverlays ? [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@matthewbauer "-static"
-> " -static"
, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
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