emacsMacport: build fails on aarch64-darwin

[shaunsingh]

Issue description

If you install emacsMacport on an aarch64-darwin machine (running nix natively) the build fails. Note that on homebrew, the emacsMacport formula (railway cat) builds fine on aarch64 and includes a prebuilt release (cask). The only arm-specific change they have is this: https://github.com/railwaycat/homebrew-emacsmacport/blob/master/patches/mac-arm-fix.diff, which patches the codesigning process.

Steps to reproduce

Install nix Modify /etc/nix/nix.conf to include the aarch64 architecture Rebuild nix run 'nix-env -iA nixpkgs.emacsMacport` to install emacs

Build fails with the following output:

[  6%] Building CXX object lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoHooks.osx.dir/sanitizer_persistent_allocator.cc.o
[  7%] Building CXX object lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoHooks.osx.dir/sanitizer_platform_limits_linux.cc.o
[  7%] Building CXX object lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoHooks.osx.dir/sanitizer_platform_limits_netbsd.cc.o
[  7%] Building CXX object lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoHooks.osx.dir/sanitizer_platform_limits_posix.cc.o
/tmp/nix-build-compiler-rt-6.0.1.drv-0/compiler-rt-6.0.1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:202:31: error: invalid application of 'sizeof' to an incomplete type 'struct stat64'
  unsigned struct_stat64_sz = sizeof(struct stat64);
                              ^     ~~~~~~~~~~~~~~~
/tmp/nix-build-compiler-rt-6.0.1.drv-0/compiler-rt-6.0.1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:202:45: note: forward declaration of '__sanitizer::stat64'
  unsigned struct_stat64_sz = sizeof(struct stat64);
                                            ^
/tmp/nix-build-compiler-rt-6.0.1.drv-0/compiler-rt-6.0.1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:227:33: error: invalid application of 'sizeof' to an incomplete type 'struct statfs64'
  unsigned struct_statfs64_sz = sizeof(struct statfs64);
                                ^     ~~~~~~~~~~~~~~~~~
/tmp/nix-build-compiler-rt-6.0.1.drv-0/compiler-rt-6.0.1.src/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:227:47: note: forward declaration of '__sanitizer::statfs64'
  unsigned struct_statfs64_sz = sizeof(struct statfs64);
                                              ^
2 errors generated.
make[2]: *** [lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoHooks.osx.dir/build.make:303: lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoHooks.osx.dir/sanitizer_platform_limits_posix.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:764: lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoHooks.osx.dir/all] Error 2
make: *** [Makefile:149: all] Error 2
builder for '/nix/store/b11kjv1kkh489zr3hi0iscq62faa45bw-compiler-rt-6.0.1.drv' failed with exit code 2
building '/nix/store/s6r151m6wsm7xs0y777vfqhdf1fa122f-apple-framework-Quartz-11.0.0.drv'...
cannot build derivation '/nix/store/gq19zfgabj5b53frj43vlk69lprdi9db-clang-wrapper-6.0.1.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/axmp969633hzkbl4733xl4w44sq6n034-stdenv-darwin.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/sxjawx6ls6n1s5c2lnm1vblynpc9mfl6-emacs-mac-27.2-8.2.drv': 1 dependencies couldn't be built
error: build of '/nix/store/sxjawx6ls6n1s5c2lnm1vblynpc9mfl6-emacs-mac-27.2-8.2.drv' failed
```zsh

## Technical details

Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.
```zsh
 - system: `"aarch64-darwin"`
 - host os: `Darwin 21.0.0, macOS 12.0`
 - multi-user?: `no`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.3.12`
 - channels(shauryasingh): `"nixpkgs-21.11pre297243.b27eaa18b47, unstable-21.11pre297243.b27eaa18b47"`
 - nixpkgs: `/Users/shauryasingh/.nix-defexpr/channels/nixpkgs`

[npajkovsky]

Why is it compiled with ugly old llvm6?

[npajkovsky]

Aha, so when I have updated the llvm6 to llvm11 for emacsMacports

stdenv = if stdenv.cc.isClang then llvmPackages_11.stdenv else stdenv;

I have got another build issue.

./macappkit.h:30:9: fatal error: 'UniformTypeIdentifiers/UniformTypeIdentifiers.h' file not found
#import <UniformTypeIdentifiers/UniformTypeIdentifiers.h>
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

[npajkovsky]

I have working build.

[npajkovsky]

The patch below fix the build issue on aarch64-darwin. The terminal emacs binary works like charm, but it's very different story for Emacs.app, because it segfaults

> % ~/.nix-profile/Applications/Emacs.app/Contents/MacOS/Emacs -Q
Fatal error 11: Segmentation fault
Backtrace:
0   Emacs                               0x0000000104fac34c deliver_thread_signal + 60
1   Emacs                               0x0000000104faacf8 seed_random + 0
2   Emacs                               0x0000000104fac3c8 handle_sigsegv + 64
3   libsystem_platform.dylib            0x000000018b656c44 _sigtramp + 56
4   libobjc.A.dylib                     0x000000018b4c680c _ZN19AutoreleasePoolPage12releaseUntilEPP11objc_object + 204
5   libobjc.A.dylib                     0x000000018b4a4e0c objc_autoreleasePoolPop + 212
6   Emacs                               0x00000001050d937c mac_gui_loop + 92
7   Emacs                               0x00000001050d92a8 main + 1116
8   libdyld.dylib                       0x000000018b629430 start + 4

This is were I can help more.

pkgs/applications/editors/emacs/macport.nix | 12 +++++++++---
 pkgs/top-level/all-packages.nix             |  5 +++--
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/pkgs/applications/editors/emacs/macport.nix b/pkgs/applications/editors/emacs/macport.nix
index 8c395219aeb3..358890960870 100644
--- a/pkgs/applications/editors/emacs/macport.nix
+++ b/pkgs/applications/editors/emacs/macport.nix
@@ -1,5 +1,5 @@
-{ lib, stdenv, fetchurl, ncurses, pkg-config, texinfo, libxml2, gnutls, gettext, autoconf, automake, jansson
-, AppKit, Carbon, Cocoa, IOKit, OSAKit, Quartz, QuartzCore, WebKit
+{ lib, stdenv, fetchurl, fetchpatch, ncurses, pkg-config, texinfo, libxml2, gnutls, gettext, autoconf, automake, jansson
+, AppKit, Carbon, Cocoa, IOKit, OSAKit, Quartz, QuartzCore, WebKit, UniformTypeIdentifiers, sigtool
 , ImageCaptureCore, GSS, ImageIO # These may be optional
 }:

@@ -26,12 +26,18 @@ stdenv.mkDerivation rec {
     sha256 = "0f2wzdw2a3ac581322b2y79rlj3c9f33ddrq9allj97r1si6v5xk";
   };

+  patches = fetchpatch {
+      name = "fix-aarch64-darwin-triplet.patch";
+      url = "https://git.savannah.gnu.org/cgit/emacs.git/patch/?id=a88f63500e475f842e5fbdd9abba4ce122cdb082";
+      sha256 = "sha256-RF9b5PojFUAjh2TDUW4+HaWveV30Spy1iAXhaWf1ZVg=";
+  };
+
   enableParallelBuilding = true;

   nativeBuildInputs = [ pkg-config autoconf automake ];

   buildInputs = [ ncurses libxml2 gnutls texinfo gettext jansson
-    AppKit Carbon Cocoa IOKit OSAKit Quartz QuartzCore WebKit
+    AppKit Carbon Cocoa IOKit OSAKit Quartz QuartzCore WebKit UniformTypeIdentifiers sigtool
     ImageCaptureCore GSS ImageIO   # may be optional
   ];

diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index 01c955087234..7aa55b682447 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -23899,9 +23899,10 @@ with pkgs;

   emacsMacport = callPackage ../applications/editors/emacs/macport.nix {
     inherit (darwin.apple_sdk.frameworks)
-      AppKit Carbon Cocoa IOKit OSAKit Quartz QuartzCore WebKit
+      AppKit Carbon Cocoa IOKit OSAKit Quartz QuartzCore WebKit UniformTypeIdentifiers
       ImageCaptureCore GSS ImageIO;
-    stdenv = if stdenv.cc.isClang then llvmPackages_6.stdenv else stdenv;
+    inherit (darwin) sigtool;
+    stdenv = if stdenv.cc.isClang then llvmPackages_11.stdenv else stdenv;
   };

   emacsPackagesFor = emacs: import ./emacs-packages.nix {

[peterbecich]

Label suggestion: "6.topic: emacs" https://github.com/NixOS/nixpkgs/labels/6.topic%3A%20emacs

[srid]

Why is it compiled with ugly old llvm6?

I get this exact error with compiler-rt-libc-9.0.1. https://github.com/srid/haskell-template/issues/1#issuecomment-979513860

[npajkovsky]

@srid Highly likely. Try a bit saner version of llvm.

[soulomoon]

Why is it compiled with ugly old llvm6?

I get this exact error with compiler-rt-libc-9.0.1. srid/haskell-template#1 (comment)

compiler-rt{5,6,7,8,9,10} are marked broken in aarch64-darwin, broken

[Atemu]

In the process of integrating macport into the generic emacs drv, I also wanted to make it build on regular stdenv and ran across this issue.

What I've noticed though: The crash only happens sometimes. If you run it a couple times, you get a Window that works just as expected though it did crash later on me.
This leads me to believe it's either a bug in the GUI handling of macport or it's because of our use of ancient system libraries.

[npajkovsky]

@Atemu There's a new version of macport and maybe it's fixed. It should not be a problem to build it on stdenv. If I recall correctly, it worked.

I can give it a shake this week.

[Atemu]

Do you mean the experimental emacs28 version? The reason for my PR is actually to not have to duplicate the native-comp infra of the generic drv for that version.

I'm in the process of trying it out now.

[npajkovsky]

@Atemu Ouch. Sorry, my bad. I thought that a new version of macport was released[1]

[1] https://bitbucket.org/mituharu/emacs-mac/downloads/?tab=tags

[Atemu]

Well, sort of. It's not officially "released" yet but Yamamoto-san pushed emacs-28 to their work branch: https://bitbucket.org/mituharu/emacs-mac/branch/work

The derivation from my PR above works now and can be used with that branch too FYI. Newer stdenv still doesn't work though unfortunately.

[npajkovsky]

That's great news. What's the issue now? I had to add UniformTypeIdentifiers to get it built.

[Atemu]

I actually don't own an aarch64-darwin mac yet, this is just an oddity I wanted to get rid of during the refactor since the regular NS emacs is also built on regular stdenv.

It builds just fine with newer llvm but it still crashes just like before: https://github.com/NixOS/nixpkgs/issues/127902#issuecomment-1014402871

[Atemu]

Does it work with Apple clang perhaps? Something worth trying.

The sandbox is not enforced on macOS, so you could just set CC to /usr/bin/cc etc.

[SirensOfTitan]

Running into similar problems on aarch64-darwin here with my own emacs-mac overlay based on Yamamoto's work branch. I can get successful builds, working libgccjit support, but graphical eventually segfaults (usually immediately, occasionally I can get as far as bringing up projectile before I beachball).

I've tried trying different llvm versions to same effect. I'll try building using Apple clang tonight and see where it gets me.

[teehemkay]

@SirensOfTitan any update on building w/ Apple clang?

[SirensOfTitan]

@teehemkay: No go, I still get crashes. I'd classify myself as a nix novice though, perhaps I did something wrong. @Atemu: any ideas or instructions from you and I'm happy to try them out. Will try to be a little more responsive.

From lldb:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x000000019ed50334 libobjc.A.dylib`objc_msgSend + 52
libobjc.A.dylib`objc_msgSend:
->  0x19ed50334 <+52>: ldp    x17, x9, [x13], #-0x10
    0x19ed50338 <+56>: cmp    x9, x1
    0x19ed5033c <+60>: b.ne   0x19ed5034c               ; <+76>
    0x19ed50340 <+64>: eor    x10, x10, x1
Target 0: (emacs-28.0.91) stopped.

Applications/Emacs.app/Contents/MacOS/Emacs -Q:

Fatal error 11: Segmentation fault
Backtrace:
0   Emacs                               0x000000010022386c deliver_thread_signal + 60
1   Emacs                               0x0000000100221fc4 seed_random + 0
2   Emacs                               0x00000001002238e8 handle_sigsegv + 64
3   libsystem_platform.dylib            0x000000019eedc4e4 _sigtramp + 56
4   libobjc.A.dylib                     0x000000019ed5738c _ZN19AutoreleasePoolPage12releaseUntilEPP11objc_object + 200
5   libobjc.A.dylib                     0x000000019ed53d68 objc_autoreleasePoolPop + 208
6   Emacs                               0x0000000100368630 mac_gui_loop + 92
7   Emacs                               0x000000010036855c main + 1116
8   dyld                                0x0000000100c250f4 start + 520
[1]    54325 segmentation fault  Applications/Emacs.app/Contents/MacOS/Emacs -Q

[LoganBarnett]

Looks like there's at least two pull requests converging on this: #155360 by @Atemu and #138424 by @mikroskeem.

I'm not versed enough with nix nor building from source to know which one of these are further along. From what I've gathered @Atemu's PR is trying to roll the emacsMacport derivation into the standard Emacs derivation (and therefore adding aarch64 support) and @mikroskeem is just trying to get the emacsMacport derivation working on aarch64.

I apologize in advance if my ignorance here misrepresents the efforts here. Thanks for all the help!

[Atemu]

No, what I'm trying to do is get rid of the extra macport derivation to make it easier to add things like using native-comp to macport. I also wanted to get rid of the stdenv override so that it builds on aarch64 but I wasn't able to.
I have tried integrating @mikroskeem's patches as I do have an aarch64-darwin machine now but they don't actually seem to work.

Right now, my PR is in development hell as there's an issue I cannot debug. I think I might just build macport from source instead, I don't really see the point in using release tarballs anyways.

[flurie]

I'm actively working on reestablishing a baseline for emacsMacport for aarch64-darwin. My goal is to get it running and then slowly add back things or fix extreme changes as needed. I pulled in some stuff from @mikroskeem's work, and I've been looking at what's common among the macports and homebrew builds. I was getting the same segfaults everyone else seemed to be experiencing when using various clang envs, but they disappeared when I went nuclear witih CC=/usr/bin/clang. Replacing that, even with a clang13 stdenv, seems to bring back the intermittent segfaults. I noticed as well that the homebrew formula has a hack for getting the codesign working, but not having that doesn't seem to impede running the version built with Xcode clang.

Perhaps someone who is more familiar with the macport code has an idea of what's going on here? I'm not opposed to doing what some other packages need to do in order to build, but I hope to understand a bit more about why it's necessary.

[Atemu]

Interesting that it doesn't crash when built with Apple clang. I'd have assumed it's due to some outdated system libraries (the bringup is WIP but has been long and painful AFAIK) but I don't think Apple clang will use that in a drv? There's nothing preventing it though.

Could you double check Apple clang'd Emacs is linked against Nixpkgs' libsystem and not the regular one?

[flurie]

aha, good thinking.

❯ otool -L result/bin/emacs
result/bin/emacs:
        /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 165.0.0)
        /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit (compatibility version 1.0.0, current version 613.1.17)        /System/Library/Frameworks/Quartz.framework/Versions/A/Quartz (compatibility version 1.0.0, current version 1.0.0)
        /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.11.0)
        /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
        /System/Library/Frameworks/OSAKit.framework/Versions/A/OSAKit (compatibility version 1.0.0, current version 113.0.0)
        /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
        /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface (compatibility version 1.0.0, current version 1.0.0)
        /System/Library/Frameworks/UniformTypeIdentifiers.framework/Versions/A/UniformTypeIdentifiers (compatibility version 1.0.0, current version 709.0.0)
        /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
        /nix/store/qqp3sbsh57n33ppkrl8sby7f7gpgli84-libxml2-2.9.13/lib/libxml2.2.dylib (compatibility version 12.0.0, current version 12.13.0)
        /nix/store/piz5f9n6pyj947jvn0wg54iw1an6w1pw-ncurses-6.3/lib/libncursesw.6.dylib (compatibility version 6.0.0, current version 6.0.0)
        /nix/store/vx9v678g9gxwqgihd3s44g1mb2q1cgwq-gnutls-3.7.3/lib/libgnutls.30.dylib (compatibility version 62.0.0, current version 62.0.0)
        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
        /nix/store/ms2973z4qbddbwnl3xgkqwiwza0fcmmm-jansson-2.13.1/lib/libjansson.4.dylib (compatibility version 18.0.0, current version 18.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)
        /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2113.40.126)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1858.112.0)
        /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1557.5.4)
        /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage (compatibility version 1.0.1, current version 5.0.0)
        /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1141.1.0)
        /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText (compatibility version 1.0.0, current version 1.0.0)
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1858.112.0)
        /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO (compatibility version 1.0.0, current version 1.0.0)
        /System/Library/Frameworks/PDFKit.framework/Versions/A/PDFKit (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

Unless I'm mistaken, we could start swapping these out to figure out which library is causing the segfaults. Do I have to add the library paths to the build command explicitly? Will clang not use the build shell path to resolve those? Please forgive my lack of C build knowledge.

[Atemu]

Sorry, I don't know either.

Perhaps @toonn could help you with that, they're very knowledgable when it comes to Darwin and its stdenv.

[toonn]

I think we can change out dylibs one by one using install_name_tool?

[flurie]

Okay, I think I have a sense for how to do that based on the prior art sprinkled in nixpkgs. I can take the otool -L list for the successful build with /usr/bin/clang and add an install_name_tool -add_rpath /path/to/dylib $bin/emacs one at a time. I'm guessing I should skip the ones that match, but for a few that "match" they seem to be off by very minor versions, and I can't really reconcile how they find those versions, since they seem to use the same abspath. You'll have to forgive me, because I don't really build C/Objc for darwin in general, so if I've made any incorrect or incomplete assumptions, please correct me.

[toonn]

I don't think you want -add_rpath actually. That's only for paths that use @rpath/some/where.dylib. I think you'll want to use -change.

[dhess]

Anyone made any progress on this?

[divanorama]

Tried to build with latest nixpkgs and following patch

diff --git a/pkgs/applications/editors/emacs/generic.nix b/pkgs/applications/editors/emacs/generic.nix
index d6ce650fb8a..e124600ce92 100644
--- a/pkgs/applications/editors/emacs/generic.nix
+++ b/pkgs/applications/editors/emacs/generic.nix
@@ -7,7 +7,7 @@
   , patches ? _: [ ]
   , macportVersion ? null
 }:
-{ stdenv, llvmPackages_6, lib, fetchurl, fetchpatch, substituteAll, ncurses, libXaw, libXpm
+{ stdenv, lib, fetchurl, fetchpatch, substituteAll, ncurses, libXaw, libXpm
 , Xaw3d, libXcursor,  pkg-config, gettext, libXft, dbus, libpng, libjpeg, giflib
 , libtiff, librsvg, libwebp, gconf, libxml2, imagemagick, gnutls, libselinux
 , alsa-lib, cairo, acl, gpm, m17n_lib, libotf
@@ -17,7 +17,7 @@
 , fetchFromSavannah, fetchFromBitbucket

   # macOS dependencies for NS and macPort
-, AppKit, Carbon, Cocoa, IOKit, OSAKit, Quartz, QuartzCore, WebKit
+, AppKit, Carbon, Cocoa, IOKit, OSAKit, Quartz, QuartzCore, WebKit, UniformTypeIdentifiers
 , ImageCaptureCore, GSS, ImageIO # These may be optional

 , withX ? !stdenv.isDarwin && !withPgtk
@@ -60,7 +60,7 @@ assert withPgtk -> withGTK3 && !withX && gtk3 != null;
 assert withXwidgets -> withGTK3 && webkitgtk != null;

-let emacs = (if withMacport then llvmPackages_6.stdenv else stdenv).mkDerivation (lib.optionalAttrs nativeComp {
+let emacs = stdenv.mkDerivation (lib.optionalAttrs nativeComp {
   NATIVE_FULL_AOT = "1";
   LIBRARY_PATH = "${lib.getLib stdenv.cc.libc}/lib";
 } // {
@@ -159,7 +159,7 @@ let emacs = (if withMacport then llvmPackages_6.stdenv else stdenv).mkDerivation
     ++ lib.optionals (withX && withXwidgets) [ webkitgtk glib-networking ]
     ++ lib.optionals withNS [ AppKit GSS ImageIO ]
     ++ lib.optionals withMacport [
-      AppKit Carbon Cocoa IOKit OSAKit Quartz QuartzCore WebKit
+      AppKit Carbon Cocoa IOKit OSAKit Quartz QuartzCore WebKit UniformTypeIdentifiers
       # TODO are these optional?
       ImageCaptureCore GSS ImageIO
     ]
diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index 3bccd62544d..91d971150da 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -28341,7 +28341,7 @@ with pkgs;
     gconf = null;

     inherit (darwin.apple_sdk.frameworks)
-      AppKit Carbon Cocoa IOKit OSAKit Quartz QuartzCore WebKit
+      AppKit Carbon Cocoa IOKit OSAKit Quartz QuartzCore WebKit UniformTypeIdentifiers
       ImageCaptureCore GSS ImageIO;
     inherit (darwin) sigtool;
   };

builds ok, but can't verify if it works well not being a emacs user, also emacsMacport.passthru.tests fail to build with

error: assertion '(stdenv).isLinux' failed

       at /Users/....../nixpkgs/pkgs/os-specific/linux/kernel/generic.nix:71:1:

           70|
           71| assert stdenv.isLinux;
             | ^
           72|

[dhess]

I'll try it out and leave some feedback. Thank you!

[Atemu]

@divanorama just open it a few times, it should crash rather quickly.

[npajkovsky]

I have switched to plain Emacs, and I don't see any difference. The emacsMacport maintainer never responded to my email that described this issue.

[Atemu]

@npajkovsky just because you don't notice a difference doesn't mean there is none.

This issue is on our end, not theirs. At best they could provide some pointers what it is we do that might cause the issue.

[divanorama]

@divanorama just open it a few times, it should crash rather quickly.

ok, tried to open-close couple of times, a little bit of browsing around - no crashes so far

[willemml]

Have you tried the work branch from the emacs-mac repo? That has a few fixes for some crashes that were happening, especially on Ventura.

[kfiz]

I don't think you want -add_rpath actually. That's only for paths that use @rpath/some/where.dylib. I think you'll want to use -change.

@flurie This approach seems to make sense. Have you had a chance to move on with this?

[actionshrimp]

@divanorama 's patch is working great for me here for terminal emacs (launched from ./result/bin/emacs) - performance seems better than the regular emacs package for general usage (although not much of a boost for magit which I was hoping for).

Trying to launch gui emacs gives:

$ ./result/Applications/Emacs.app/Contents/MacOS/Emacs
Fatal error 11: Segmentation fault
Backtrace:
0   Emacs                               0x00000001042d7bd4 deliver_thread_signal + 56
1   Emacs                               0x00000001042d628c seed_random + 0
2   Emacs                               0x00000001042d7c58 handle_sigsegv + 64
3   libsystem_platform.dylib            0x000000018ac202a4 _sigtramp + 56
4   libobjc.A.dylib                     0x000000018a88c168 _ZN19AutoreleasePoolPage12releaseUntilEPP11objc_object + 196
5   libobjc.A.dylib                     0x000000018a888870 objc_autoreleasePoolPop + 256
6   Emacs                               0x000000010440d6d0 mac_gui_loop + 100
7   Emacs                               0x000000010440d5f4 main + 1136
8   dyld                                0x000000018a8c7e50 start + 2544
zsh: segmentation fault  ./result/Applications/Emacs.app/Contents/MacOS/Emacs

[flurie]

I don't think you want -add_rpath actually. That's only for paths that use @rpath/some/where.dylib. I think you'll want to use -change.

@flurie This approach seems to make sense. Have you had a chance to move on with this?

Sorry, I switched to Linux at work and this dropped in priority for me, but I have some time to take a look at it now.

Unfortunately, with the macport derivation merged into the generic derivation, I can't use the nuclear option of overriding with system clang anymore, because it can't find libgccjit in however the autoreconfHook is running autoconf, and switching back to autoconf/automake seems to need some sort of path override, because it wants to write to all sorts of /usr/local/share directories, so I can't build the derivation as needed to try this anymore. I'm also not sure if the shared libraries are the culprit, because the way the current derivation with the patches is failing is curiously deterministic. The first invocation fails with this:

❯ ./result/Applications/Emacs.app/Contents/MacOS/Emacs
objc[40243]: Attempt to use unknown class 0x10ebd12b0.
Fatal error 6: Aborted
Backtrace:
0   Emacs                               0x0000000104b87b40 deliver_thread_signal + 56
1   Emacs                               0x0000000104b861f8 seed_random + 0
2   libsystem_platform.dylib            0x00000001850a72a4 _sigtramp + 56
3   libsystem_kernel.dylib              0x000000018506ae54 abort_with_payload_wrapper_internal + 104
4   libsystem_kernel.dylib              0x000000018506adec abort_with_payload_wrapper_internal + 0
5   libobjc.A.dylib                     0x0000000184d393d8 _ZL12_objc_fatalvyyPKcPc + 128
6   libobjc.A.dylib                     0x0000000184d39358 _ZL12_objc_fatalvyyPKcPc + 0
7   libobjc.A.dylib                     0x0000000184d0e160 lookUpImpOrForward + 784
8   libobjc.A.dylib                     0x0000000184d0db64 _objc_msgSend_uncached + 68
9   libobjc.A.dylib                     0x0000000184d14168 _ZN19AutoreleasePoolPage12releaseUntilEPP11objnded from macro '__deprecated_msg'                                                                   c_object + 196
10  libobjc.A.dylib                     0x0000000184d10870 objc_autoreleasePoolPop + 256
11  Emacs                               0x0000000104cbd638 mac_gui_loop + 100
12  Emacs                               0x0000000104cbd55c main + 1136
13  dyld                                0x0000000184d4fe50 start + 2544
[2]    40243 abort      ./result/Applications/Emacs.app/Contents/MacOS/Emacs

The second invocation segfaults during window instantiation.

The third invocation fails the same as the first.

The fourth invocation manages to stick around for a while, and it only segfaults when I do specific things, usually file access related. Then the cycle repeats.

If someone has a suggestion for getting system clang working with the existing derivation, I'd be happy to continue along the path.

[Atemu]

@flurie for your libgccjit problem, you could simply disable override nativeComp = false. It won't be used at all then (you don't need it for debugging).

[flurie]

@Atemu good call, that gets me a working nuclear derivation again. Unfortunately, no amount of modifying the shared libraries seems to affect the central issue. It looks like macvim takes the nuclear option. Should we just figure out handling that for emacsMacport?

[Atemu]

I don't think that approach is something we should strive for. It's impure which means we don't get any hydra builds. We need emacsMacport to be built by hydra because nativeComp needs like 15+ minutes on a reasonably fast machine.

[bestlem]

I am new to nix so this could be a silly question.

What version of clang is being used? The clang port says 11 and I think https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/darwin/default.nix is using 11 as well.

Ventura Apple clang is Apple clang version 14.0.0 (clang-1400.0.29.202)

So shouldn't we be using clang-14?

[Atemu]

The emacsMacport derivation explicitly uses llvm7 rather than the default because newer versions somehow cause crashes.

[bestlem]

@Atemu that was done some time ago. Is it true now with llvm 14 or 15?

I come from the Mac±/ports world where you have to have a different Xcode for each version of macOS. That is probably because of the Apple SDK but the version of clang also changes.

I also have had nix emacs crash on me but not used much as I am still learning.

[Atemu]

Correction: It's LLVM6: https://github.com/NixOS/nixpkgs/blob/36699e98e417593eb7f90efd5ea87bc517caf413/pkgs/applications/editors/emacs/generic.nix#L63

@bestlem I tried 13 or 14 with the same error. 15 is not in Nixpkgs yet.

Here in Nixpkgs, we can have any version of clang we like (or even gcc if we feel like it) and theoretically any version of of the "SDK", as in Libsystem etc. and frameworks but we only have two packaged; only one for aarch64.

The actual problem probably isn't even caused by the compiler but using an older version somehow masks it. That old version doesn't support aarch64-darwin however.

Nix' emacs shouldn't crash any more than regular Emacs. If it does, that's a bug.

[shaunsingh]

If clang keeps crashing we could give it a try with gccStdenv instead ... I imagine it would be a requirement to use libgccjit

[Atemu]

gccStdenv causes no GUI toolkit to be built at all for some odd reason.

libgccjit works with clang and has been working in macPort for a while.

[tnytown]

I attempted to triage the issue and I think I got it: tnytown/nixpkgs-overlay-tny@03deb1490dd98c93a7eb0939d4a9a0c136a6b159 It seems to be working on macOS 13.2. You can test it with Flakes by running nix build github:tnytown/nixpkgs-overlay-tny#emacsMacport, then open result/Applications/Emacs.app. I want to try to get this patch into nixpkgs if it works on other machines and if it doesn't cause any runtime regressions with x86_64.

[Atemu]

How and why would that patch fix it? Also, why does it require a new header when there's no header change?

Emacs seems to be running quite stably with it but executing any action on the menu bar causes an immediate crash.

Nixpkgs patch

```patch diff --git a/pkgs/applications/editors/emacs/0002-mac-gui-loop-block-autorelease.patch b/pkgs/applications/editors/emacs/0002-mac-gui-loop-block-autorelease.patch new file mode 100644 index 00000000000..4908a01ba07 --- /dev/null +++ b/pkgs/applications/editors/emacs/0002-mac-gui-loop-block-autorelease.patch @@ -0,0 +1,28 @@ +diff --git a/src/macappkit.m b/src/macappkit.m +index babb3560c7..29b0ab3511 100644 +--- a/src/macappkit.m ++++ b/src/macappkit.m +@@ -16145,9 +16145,9 @@ - (void)sound:(NSSound *)sound didFinishPlaying:(BOOL)finishedPlaying + dispatch_semaphore_wait (mac_gui_semaphore, DISPATCH_TIME_FOREVER); + block = [mac_gui_queue dequeue]; + if (block) +- block (); +- dispatch_semaphore_signal (mac_lisp_semaphore); ++ block (); + END_AUTORELEASE_POOL; ++ dispatch_semaphore_signal (mac_lisp_semaphore); + } + while (block); + } +@@ -16161,9 +16161,9 @@ - (void)sound:(NSSound *)sound didFinishPlaying:(BOOL)finishedPlaying + dispatch_semaphore_wait (mac_gui_semaphore, DISPATCH_TIME_FOREVER); + block = [mac_gui_queue dequeue]; + eassert (block); +- block (); +- dispatch_semaphore_signal (mac_lisp_semaphore); ++ block (); + END_AUTORELEASE_POOL; ++ dispatch_semaphore_signal (mac_lisp_semaphore); + } + + /* Ask execution of BLOCK to the GUI thread synchronously. The diff --git a/pkgs/applications/editors/emacs/generic.nix b/pkgs/applications/editors/emacs/generic.nix index feed7ba5b41..9d0f48be647 100644 --- a/pkgs/applications/editors/emacs/generic.nix +++ b/pkgs/applications/editors/emacs/generic.nix @@ -7,7 +7,7 @@ , patches ? _: [ ] , macportVersion ? null }: -{ stdenv, llvmPackages_6, lib, fetchurl, fetchpatch, substituteAll, ncurses, libXaw, libXpm +{ stdenv, llvmPackages_14, lib, fetchurl, fetchpatch, substituteAll, ncurses, libXaw, libXpm , Xaw3d, libXcursor, pkg-config, gettext, libXft, dbus, libpng, libjpeg, giflib , libtiff, librsvg, libwebp, gconf, libxml2, imagemagick, gnutls, libselinux , alsa-lib, cairo, acl, gpm, m17n_lib, libotf @@ -17,7 +17,7 @@ , fetchFromSavannah, fetchFromBitbucket # macOS dependencies for NS and macPort -, AppKit, Carbon, Cocoa, IOKit, OSAKit, Quartz, QuartzCore, WebKit +, AppKit, Carbon, Cocoa, IOKit, OSAKit, Quartz, QuartzCore, WebKit, UniformTypeIdentifiers , ImageCaptureCore, GSS, ImageIO # These may be optional , withX ? !stdenv.isDarwin && !withPgtk @@ -60,7 +60,7 @@ assert withPgtk -> withGTK3 && !withX && gtk3 != null; assert withXwidgets -> withGTK3 && webkitgtk != null; -let emacs = (if withMacport then llvmPackages_6.stdenv else stdenv).mkDerivation (lib.optionalAttrs nativeComp { +let emacs = (if withMacport then llvmPackages_14.stdenv else stdenv).mkDerivation (lib.optionalAttrs nativeComp { NATIVE_FULL_AOT = "1"; LIBRARY_PATH = "${lib.getLib stdenv.cc.libc}/lib"; } // { @@ -159,7 +159,7 @@ let emacs = (if withMacport then llvmPackages_6.stdenv else stdenv).mkDerivation ++ lib.optionals (withX && withXwidgets) [ webkitgtk glib-networking ] ++ lib.optionals withNS [ AppKit GSS ImageIO ] ++ lib.optionals withMacport [ - AppKit Carbon Cocoa IOKit OSAKit Quartz QuartzCore WebKit + AppKit Carbon Cocoa IOKit OSAKit Quartz QuartzCore WebKit UniformTypeIdentifiers # TODO are these optional? ImageCaptureCore GSS ImageIO ] diff --git a/pkgs/applications/editors/emacs/macport.nix b/pkgs/applications/editors/emacs/macport.nix index 9a30b2b5b40..48acfc4648b 100644 --- a/pkgs/applications/editors/emacs/macport.nix +++ b/pkgs/applications/editors/emacs/macport.nix @@ -3,4 +3,7 @@ import ./generic.nix rec { version = "28.2"; macportVersion = "emacs-${version}-mac-9.1"; sha256 = "sha256-Ne2jQ2nVLNiQmnkkOXVc5AkLVkTpm8pFC7VNY2gQjPE="; + patches = _: [ + ./0002-mac-gui-loop-block-autorelease.patch + ]; } diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix index b538e2ad58e..700aa265a6c 100644 --- a/pkgs/top-level/all-packages.nix +++ b/pkgs/top-level/all-packages.nix @@ -29060,7 +29060,7 @@ with pkgs; gconf = null; inherit (darwin.apple_sdk.frameworks) - AppKit Carbon Cocoa IOKit OSAKit Quartz QuartzCore WebKit + AppKit Carbon Cocoa IOKit OSAKit Quartz QuartzCore WebKit UniformTypeIdentifiers ImageCaptureCore GSS ImageIO; inherit (darwin) sigtool; }; ```