emacsMacport: build fails on aarch64-darwin #127902
Comments
|
Why is it compiled with ugly old llvm6? |
|
Aha, so when I have updated the llvm6 to llvm11 for emacsMacports I have got another build issue. |
|
I have working build. |
|
The patch below fix the build issue on This is were I can help more. |
|
Label suggestion: "6.topic: emacs" |
I get this exact error with compiler-rt-libc-9.0.1. srid/haskell-template#1 (comment) |
|
@srid Highly likely. Try a bit saner version of llvm. |
compiler-rt{5,6,7,8,9,10} are marked broken in aarch64-darwin, |
|
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. |
|
@Atemu There's a new version of macport and maybe it's fixed. It should not be a problem to build it on I can give it a shake this week. |
|
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. |
|
@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 |
|
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. |
|
That's great news. What's the issue now? I had to add |
|
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: #127902 (comment) |
|
Does it work with Apple clang perhaps? Something worth trying. The sandbox is not enforced on macOS, so you could just set CC to |
|
Running into similar problems on I've tried trying different llvm versions to same effect. I'll try building using Apple clang tonight and see where it gets me. |
|
@SirensOfTitan any update on building w/ Apple clang? |
|
@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:
|
|
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 I apologize in advance if my ignorance here misrepresents the efforts here. Thanks for all the help! |
|
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. 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. |
|
I'm actively working on reestablishing a baseline for 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. |
|
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? |
|
aha, good thinking. 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. |
|
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. |
|
I think we can change out dylibs one by one using |
|
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. |
Patch mac_gui_loop in macappkit.m to fix the block lifetime issue. NixOS/nixpkgs#127902
|
I attempted to triage the issue and I think I got it: |
|
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 patchdiff --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;
}; |
|
That patch would imply a bug in Mitsuharu's port of emacs. However the original code works on Macports and Homebrew without a patch for this. Thus you might have stoped a crash but I think you have introduced a memory leak (moving things out of autorelease sections) or a race condition. It does run on my Apple Silicon mac mini. |
|
Sorry all, I should have elaborated further on what my patch is meant to do. I'll start from the top. As a disclaimer, I am not an Emacs maintainer and I do not know what I am doing. If anybody reading this has a better idea of what's going on, please chime in! First, I fixed the compilation issue by adding the Once the compilation error was fixed, I got the familiar segfault(s): $ outputs/out/Applications/Emacs.app/Contents/MacOS/Emacs Fatal error 11: Segmentation fault Backtrace: 0 Emacs 0x0000000100754e48 emacs_backtrace + 500 1 Emacs 0x0000000100d5b010 terminate_due_to_signal + 568 2 Emacs 0x000000010075aab0 deliver_thread_signal + 0 3 Emacs 0x0000000100753724 deliver_process_signal + 736 4 Emacs 0x0000000100753d88 deliver_fatal_signal + 32 5 libsystem_platform.dylib 0x00000001a29cc2a4 _sigtramp + 56 6 libdispatch.dylib 0x00000001a2816aa0 _dispatch_sema4_wait + 28 7 libdispatch.dylib 0x00000001a2817154 _dispatch_semaphore_wait_slow + 132 8 Emacs 0x0000000100cd2718 mac_within_gui_and_here + 280 9 Emacs 0x0000000100be5254 mac_within_gui + 28 10 Emacs 0x0000000100c14ec8 mac_set_frame_window_title + 928 11 Emacs 0x0000000100b2e074 mac_set_name_internal + 188 12 Emacs 0x0000000100b2de88 mac_set_name + 1100 13 Emacs 0x0000000100b33634 mac_window + 932 14 Emacs 0x0000000100b31724 Fx_create_frame + 8740 15 faces-b9447c93-029fbb21.eln 0x0000000103a3eaa0 F782d6372656174652d6672616d652d776974682d6661636573_x_create_frame_with_faces_0 + 304 16 Emacs 0x0000000100916e8c funcall_subr_1 + 1668 17 Emacs 0x0000000100916788 __funcall_subr_block_invoke + 208 18 Emacs 0x0000000100bd6b28 mac_autorelease_loop + 104 19 Emacs 0x0000000100915ce4 funcall_subr + 872 20 Emacs 0x0000000100912b34 Ffuncall + 1044 21 Emacs 0x00000001009e9dbc exec_byte_code + 11848 22 Emacs 0x000000010091e010 fetch_and_exec_byte_code + 144 23 Emacs 0x0000000100916064 funcall_lambda + 652 24 Emacs 0x0000000100912b80 Ffuncall + 1120 25 Emacs 0x000000010090c960 Fapply + 484 26 Emacs 0x0000000100916c10 funcall_subr_1 + 1032 27 Emacs 0x0000000100916788 __funcall_subr_block_invoke + 208 28 Emacs 0x0000000100bd6b28 mac_autorelease_loop + 104 29 Emacs 0x0000000100915ce4 funcall_subr + 872 30 Emacs 0x0000000100912b34 Ffuncall + 1044 31 Emacs 0x00000001009e9dbc exec_byte_code + 11848 32 Emacs 0x000000010091e010 fetch_and_exec_byte_code + 144 33 Emacs 0x0000000100916064 funcall_lambda + 652 34 Emacs 0x0000000100912b80 Ffuncall + 1120 35 frame-b40fc590-ab21ad97.eln 0x0000000109ef71c8 F6d616b652d6672616d65_make_frame_0 + 1684 36 Emacs 0x0000000100916e8c funcall_subr_1 + 1668 37 Emacs 0x0000000100916788 __funcall_subr_block_invoke + 208 38 Emacs 0x0000000100bd6b28 mac_autorelease_loop + 104 39 Emacs 0x0000000100915ce4 funcall_subr + 872 40 Emacs 0x0000000100912b34 Ffuncall + 1044 ... fish: Job 1, 'outputs/out/Applications/Emac...' terminated by signal SIGSEGV (Erreur de frontière d'adresse) To try to gain visibility into the segfault, I tried many things, including:
All of this (and more) did not yield any tangible results. What finally did lead me closer to what was happening was digging deeper into one of the crash backtraces in * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
* frame #0: 0x00000001a2631834 libobjc.A.dylib`objc_msgSend + 52
frame #1: 0x00000001a2638168 libobjc.A.dylib`AutoreleasePoolPage::releaseUntil(objc_object**) + 196
frame #2: 0x00000001a2634870 libobjc.A.dylib`objc_autoreleasePoolPop + 256
frame #3: 0x00000001009f7048 Emacs`mac_gui_loop at macappkit.m:16150:7
frame #4: 0x00000001009f6940 Emacs`main(argc=1, argv=0x000000016fdfe948) at macappkit.m:16728:3
frame #5: 0x00000001a2673e50 dyld`start + 2544
This crash occurs in the deallocation of the autorelease pool. When Objective-C objects are allocated and autoreleased, they are added to the running thread's topmost autorelease pool. Our issue is (allegedly) with an invalid object being released. How do we track down the source of that object? One potentially useful source of information that occurred to me was breakpointing the function that adds objects to the autorelease pool and printing out the objects. This was a very silly idea, as there are a lot of objects in a program like Emacs, but I decided to give it a try. It felt very tedious to do manually, so I wrote a script. Here's the latest version of that: trace.py#!/usr/bin/python3
import sys
import os
import subprocess
_p = subprocess.getoutput("lldb -P")
sys.path.append(_p.strip())
import lldb
assert len(sys.argv) >= 2
debugger = lldb.SBDebugger.Create()
debugger.SetAsync(False)
def _eval(c):
rtn = lldb.SBCommandReturnObject()
interp = debugger.GetCommandInterpreter()
interp.HandleCommand(c, rtn)
if not rtn.Succeeded():
raise Exception(rtn.GetError())
return rtn.GetOutput()
def _exec(c):
debugger.HandleCommand(c)
def _target():
return debugger.GetSelectedTarget()
def _thread():
return _target().GetProcess().GetSelectedThread()
def _frame(n=0):
return _thread().GetFrameAtIndex(n)
def _expr(e):
return _frame().EvaluateExpression(e)
def _symbol(e):
addr = _target().ResolveLoadAddress(e)
return _target().ResolveSymbolContextForAddress(addr, lldb.eSymbolContextEverything)
def _thr_not_stopped():
return _thread().GetStopReason() != lldb.eStopReasonException
target = debugger.CreateTarget(sys.argv[1])
assert target
# mac_gui_loop > if(block) ...
_exec("b macappkit.m:16146")
pool_bp = target.BreakpointCreateByName("_objc_rootAutorelease")
assert pool_bp
pool_bp.enabled = False
proc = target.LaunchSimple([], [f"{k}={v}" for k, v in os.environ.items()], os.getcwd())
assert proc
# _exec("c")
while proc.state is not lldb.eStateCrashed and _thr_not_stopped():
print(_frame().name)
pool_bp.enabled = True
_eval("thread until 16149")
in_fn = _frame().name
while "_objc_rootAutorelease" in in_fn and _thr_not_stopped():
obj = _expr("(id) $x0")
print(f"autoreleased: 0x{obj.unsigned:X}, {obj.GetObjectDescription()}")
_eval("fr se 1")
_exec("fr inf")
# print(in_fn, "continuing")
proc.Continue()
pool_bp.enabled = False
print("--- mac_gui_loop ---")
addr = _expr("*((uint64_t*) block + 2)")
# _exec("po (id) block")
sym = _symbol(addr.unsigned)
print("0x{:X}, {}".format(addr.unsigned, sym.symbol.name))
proc.Continue()
#_exec("po (id) block")
_exec("bt")
_exec("br list")
# _("thr ba all")
while True:
cmd = input("] ")
_exec(cmd)This script prints out all autoreleased objects from execution of This happened to match one of the objects that was printed! (Notice the matching address, This was an Objective-C block from How does an object that cannot be deallocated get deallocated? It turns out that in this instance, the compiler constructed This brings me to my patch: patchdiff --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. TheThe Emacs Mac port handles Lisp execution on a thread separate from the GUI thread. It seems like these threads are meant to be cooperative, that is, they block on one another and yield when a task needs to be done by the other. The patch moves the yield in the main GUI thread loop outside of the loop's autorelease pool. Why does this matter? Let's walk through a hypothetical scenario with the old code. [LISP] denotes an operation on the Lisp thread. [MAIN] denotes an operation on the main thread. (Concurrently) denotes an operation that is concurrent with operations on the opposite thread. Ordering of concurrent options is variable.
Moving the Lisp semaphore signal operation out of the autorelease pool is one way of solving this issue. Now for Q&A!
With the patch, the Lisp thread will not invalidate
Yikes, that is not good :( I will investigate the menu bar issue when I have spare time. I spent quite a lot tracking this issue down.
Fair point. I am not sure why the non-Nix versions work. My pet theory is that deep in the bowels of Apple, there exists a
It is possible that there is a memory leak. However, the memory leak will be present in the context of the Lisp thread, which does not have an autorelease pool. I cannot guess the maintainer's intentions, but I do not think that the author of the Mac port intended for Lisp thread objects to end up in the GUI autorelease pool. My current Emacs instance on my work machine is sitting at ~300MB of memory usage. It's been open for two days and has gone through heavy use (magit, lsp-mode, etc). If there is a memory leak, it doesn't seem to be egregious. As for the race condition, I think I have conclusively tracked down a race condition in the unchanged code compiled with Nix
Glad to hear it works for you! |
|
@tnytown Thanks a lot for digging into this and the write-up! Could you post your findings towards YAMAMOTO Mitsuharu? Perhaps he has more ideas what might be going on here or how to fix it properly. |
|
A good writeup but... |
GitHub user @tnytown did an incredible job figuring out the cause of emacsMacport crashing: NixOS/nixpkgs#127902 (comment) Bless your soul, @tnytown.
|
@tnytown nice writeup! |
|
@tnytown Would you be interested into turning your writeup into a PR? I am interested into dropping LLVM6 and emacsMacport is the last obstacle for this. |
I'll be open to doing this, @RaitoBezarius! Unfortunately, my changes do not completely fix the issues with the Mac port. As mentioned earlier, there are still bugs with OS integration. I'm still working on fixing those issues, at which point I plan on upstreaming the changes for a more permanent solution. If there's any appetite for it, I can try to get these changes as-is into nixpkgs, keeping these issues in mind. Another option is to just mark the package as broken. |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/is-it-currently-possible-to-use-emacs-on-aarch64-darwin/31571/1 |
|
Has anyone had any success building the recently merged in emacs29-macport from #246203? Like others I've enabled Homebrew and using the railwaycat formula with success. I tried to review the overlays and patches posted but as a Nix begineer its not clear how I am meant to leverage them. If someone can point me to a guide or list out some steps I'm happy to try it out. |
|
@nathanscully I have confirmed that the same crash is present with the current 29.1 derivation, but am looking to test against #241692 and potentially #229210 when I can. I am skeptical of the above patch; there's nothing nix-specific about it and given the extent to which apple freely contributes patches in llvm upstream (per git log grep, 5307 commits with apple email addresses since 2020), I don't think it would make sense that they've been internally maintaining a patch for fixes to core objective-c language features like autorelease. More likely IMO is that some component in the dependency chain of this package is omitting a barrier that goes unnoticed under other platforms because of how weakly-ordered armv8a is, and we're just using a super old toolchain here. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 for an example. As for testing, you can just clone nixpkgs, hack on |
|
The LLVM breakage is unrelated to emacs. LLVM6 is ancient and actualy due for removal but we need it for building a non-crashing macport some reason. LLVM6 does not support modern aarch64-darwin, it's no surprise that it's broken. Given the status of LLVM6, macport will soon be broken on x86_64-darwin too. |
|
@Atemu I know we discussed some of this IRL, feel free to clean up this and put me as a reviewer for removals. |
|
I worked on this a bit more and discovered the root cause of the issue. First off, changes are on my overlay as usual. I also opened a draft PR if there's any interest in getting these changes into nixpkgs. More testers would be appreciated: the menu bar and context menu crashes should be gone, but there may be other bugs lurking. I am contacting the maintainer to find a solution upstream. TL;DR: I have empirically observed differences between how LLVM If you're curious about how I came to this conclusion, read on! As I mentioned in my previous comment, the Mac port operates two threads that schedule tasks on each other. These tasks are Objective-C blocks that are constructed on one thread, then executed on the other. This would lead to situations where one thread would reference a block that was no longer valid because the other thread had continued execution and popped the stack frame that defined the block. My older patch fixed an instance of this use after stack return in the main loop, but unfortunately that was not enough to resolve all instability. To resolve the menu bar crash, I decided to approach the problem from a different angle. I downloaded a known-good Homebrew build and diffed it against my own. One interesting difference was in how blocks were constructed: Excerpt from Nix's
|
I don't think that's totally right -- https://clang.llvm.org/docs/AttributeReference.html#noescape
The example file that you've posted is doing this, too: If emacs-macport is doing something similar, it's 100% a bug on his end. |
Sorry, I worded this poorly. What I meant was that in this context, I want to clarify that I find both approaches (respecting
That is how I understand it as well :)
Anyway, the system |
|
Sorry to jump in, but I just wanted to thank @tnytown for the great work with the investigations, patches and fixes, and other folks involved to get them shipped! 🥰 With the latest fix following #252244 and #252611, I got my build to finally succeed and not crash randomly on my M1 machine for the first time. It may be a bit too early to celebrate, but it's simply amazing to see investigations and fixes with such great details, and while I have learned a lot of technical details in there, the way this issue was tackled is a treasure in itself. Thank you very much for the inspiring work! |
|
I've also just installed |
|
+1 @tnytown - thanks for the hard work here (and all the reviewers across the threads). |
and others
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.confto include the aarch64 architectureRebuild nix
run 'nix-env -iA nixpkgs.emacsMacport` to install emacs
Build fails with the following output:
The text was updated successfully, but these errors were encountered: