Build failure: Wezterm (x86-64 darwin) #239384
Labels
0.kind: build failure
A package fails to build
6.topic: darwin
Running or building packages on Darwin
Comments
|
Looks like the same error as in #231291 |
|
cc @NixOS/darwin-maintainers |
|
My first thought is that it might be using an older sdk on |
|
This does look like an SDK issue. The annotation states it's only available from 10.16, which is 11. Try calling the package with |
|
That's already the case: wezterm = darwin.apple_sdk_11_0.callPackage ../applications/terminal-emulators/wezterm {
inherit (darwin.apple_sdk_11_0.frameworks) Cocoa CoreGraphics Foundation UserNotifications System;
}; |
|
Apparently this might be a toolchain bug? Some stuff I dug up:
I'm not sure if we're running into the exact same thing or what that thing even is though. It looks like |
|
See mono/mono#19393 (comment) in particular. |
|
Hmm, puzzling. Maybe similar to #233815? The 10.12 Libsystem being brought in somehow? I don't think the deployment target should matter. If it's older than 11 the symbol should be linked weakly. |
|
The mono issue seems unrelated. They are/were building with |
|
FWIW, it seems to build and run fine with this diff: diff --git a/pkgs/applications/terminal-emulators/wezterm/default.nix b/pkgs/applications/terminal-emulators/wezterm/default.nix
index 9743197d832..36a8bbc8e05 100644
--- a/pkgs/applications/terminal-emulators/wezterm/default.nix
+++ b/pkgs/applications/terminal-emulators/wezterm/default.nix
@@ -88,7 +88,7 @@ rustPlatform.buildRustPackage rec {
buildFeatures = [ "distro-defaults" ];
- env.NIX_LDFLAGS = lib.optionalString stdenv.isDarwin "-framework System";
+ env.NIX_LDFLAGS = lib.optionalString stdenv.isDarwin "-U ___darwin_check_fd_set_overflow";
postInstall = ''
mkdir -p $out/nix-supportBut of course that could just be masking an underlying problem. (Though the |
I do believe this means SDK 10.12 is actually being used though so a real solution would require further digging. |
|
Do we have any other Rust packages that are using a newer SDK and that we know are definitely linking with it properly? It could be that the hooks for that stuff don't work with Rust builds. |
|
|
5 steps left on my bisect, will probably take another day. |
|
Very strange. I didn't know we even used |
|
I think I did the bisect wrong, it doesn't make much sense, |
|
Hmm, no, it does get a cache hit on 3e6aebf. Maybe it's a difference between hydra and my laptop? Will try to build it on my laptop. |
|
My understanding is that |
|
Yeah at first I thought maybe the error was different, but no I got the same linking error. |
|
Maybe it's stdenv -> openssh -> openssl -> perl -> libxcrypt. I just noticed the linking error comes from |
|
Ok the build on 3e6aebf succeeds (though it says the outputs differ). |
|
I tried reverting the commit on current master, dd05e2a, and it didn't fix the build... I don't know what's going on 😂 . |
arichtman
added a commit
to arichtman/nix
that referenced
this issue
Nov 6, 2023
|
I've reduced this down to a small repo that reproduces the error. It essentially boils down to: flake.nix: {
inputs = {
nixpkgs.url = "nixpkgs/4471857c0a4a8a0ffc7bdbeaf1b998746ce12a82";
};
outputs = { self, nixpkgs }:
let
pkgs = nixpkgs.legacyPackages.x86_64-darwin;
in {
packages.x86_64-darwin.default = pkgs.darwin.apple_sdk_11_0.callPackage (
{ rustPlatform, perl, System }:
rustPlatform.buildRustPackage {
name = "wezterm-build-error";
src = ./.;
cargoLock = { lockFile = ./Cargo.lock; };
nativeBuildInputs = [ perl ];
buildInputs = [ System ];
}
) {
inherit (pkgs.darwin.apple_sdk_11_0.frameworks) System;
};
};
}Cargo.toml: [package]
name = "wezterm-build-error"
version = "0.1.0"
edition = "2021"
[dependencies]
openssl = { version = "0.10", features=["vendored"] }
git2 = { version = "0.16", default-features = false, features = ["https"] }
I based this off of the 4471857 nixpkgs commit somewhat arbitrarily as the current nixpkgs-unstable branch when I started looking into the issue. I'm new to Nix so it's been a bit slow-going to get to this point. I wanted to share my progress in case this causes someone else to immediately understand the underlying issue. |
|
I believe the git2/libgit2-sys/openssl/openssl-sys crates are all red-herrings. I reduced my test repo down so that it just uses the cc crate to attempt compile a compile a file that only includes CoreFoundation.h and that fails with the same error. flake.nix: {
inputs = {
nixpkgs.url = "nixpkgs/4471857c0a4a8a0ffc7bdbeaf1b998746ce12a82";
};
outputs = { self, nixpkgs }:
let
pkgs = nixpkgs.legacyPackages.x86_64-darwin;
in {
packages.x86_64-darwin.default = pkgs.darwin.apple_sdk_11_0.callPackage (
{ rustPlatform }:
rustPlatform.buildRustPackage {
name = "wezterm-build-error";
src = ./.;
cargoLock = { lockFile = ./Cargo.lock; };
}
) {};
};
}Cargo.toml: [package]
name = "wezterm-build-error"
version = "0.1.0"
build = "build.rs"
edition = "2021"
[build-dependencies]
cc = "1.0.43"build.rs: fn main() {
cc::Build::new().file("inc.c").compile("inc");
}inc.c: #include <CoreFoundation/CoreFoundation.h>Error from This is leading me to believe that the cc crate is not working properly with apple_sdk_11_0. |
|
Similar issues:
And this followup:
The above issues lead me to believe that there's something else in I suppose at the very least I'm learning more and more about Nix internals and macOS SDKs :/ |
|
Would it be a valid option to have another package for Wezterm to use the binary released instead of building using rust so we can pick one or the other (I know one can build it's own derivation for that, but just asking if this could be done at the Nix packages level?) |
Closed
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: |
|
Per the above Discourse mention, I tried to build Wezterm on x86_64-darwin. Assuming I would need to determine which SDK I needed to use based on how the build failed, I built it with the default (10.12) SDK. Update: I just checked The fonts are all messed up, but I don’t know whether I need to do something to make them available. |
|
The Darwin refactor has been merged into staging. Wezterm should be fixed on staging. |
|
I've been following all the work you've been doing on this (all of macOS, really), thank you so much @reckenrode! |
siriobalmelli
added a commit
to siriobalmelli/nixpkgs
that referenced
this issue
Oct 14, 2024
Won't PR: upstream will be fixed by new SDK PR coming soon. See NixOS#239384 (comment) Signed-off-by: Sirio Balmelli <[email protected]>
|
It looks like the most recent x86_64-darwin So I'm guessing there's still some wonkiness here on x86_64? |
|
I think I've just been confused by where the apple-sdk fixes have been released. It looks like they've been merged into the |
|
Yeah, I’d expect about a week or so until it hits the channels. |
|
And to confirm: Wezterm build successfully on x86_64-darwin. |
|
Does this mean we can now close this issue or are there some points remaining? |
|
It probably should wait until staging-next is merged into master, though that’s likely not far off from now. |
|
To chime in a bit I have no luck as well. Sequoia on MBP 12,1 (x86_64-darwin), did a nix flake update and unable to build wezterm
However, wezterm is successfully installed using homebrew which I have inside nix.
|
|
We usually don't wait until staging is merged to close issues it closes because who is going to keep track of that? I easily lose track and so the issues are closed when the PR is merged. |
|
Then why do we have a “fixed on staging” label? |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/title-the-darwin-sdks-have-been-updated/55295/1 |
|
Not sure do I need to open a new issue or can use this one to report. I do apologise in advance. So I did a fresh install of the OS and nix darwin with flakes after I saw the post on discourse by @reckenrode Flake file is straight out of the installation box Some errors:
Bunch of text then at the end:
Maybe wait for another day or two for the SDK to be available on |
|
Yes, the rework has not yet hit |
|
Never mind it’s stuck because of Transmission apparently and nobody noticed. Will try to fix. (Edit: Uh never mind I think |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Build log
Builds have been failing for the past 5 days:
https://hydra.nixos.org/job/nixpkgs/trunk/wezterm.x86_64-darwin/all
Notify maintainers
@SuperSandro2000 @mimame
Metadata
The text was updated successfully, but these errors were encountered: