Emacs.app can't be opened because Apple cannot check it for malicious software

[GaryDixon]

I just downloaded the Emacs 27.2-2 emacs onto iMac running ARM64 (M1 chip) under macOS 11.4. But when I attempt to open Emacs.app, I get the message:

Emacs.app can't be opened because Apple cannot check it for malicious software. This software needs to be updated. Contact the developer for more information.

It isn't clear to me what kind of checking Apple is doing or why it is complaining about the pre-built multi-architecture image. Perhaps it is complaining about the contained Ruby script that selects an appropriate executable based upon architecture of the machine (i.e., complaining that Emacs.app is not a "fat file"). Or perhaps it is complaining about a code signing issue.

Have you any suggestions for getting around this issue?

[adamcstephens]

Navigate to /Applications in Finder, right click on the Emacs application and choose Open. You will then be able to bypass this error message.

[GaryDixon]

When I tried the bypass recommended above (right-click on /Applications/Emacs.app and click Open), I got a similar warning panel:

"Emacs.app" can't be opened because Apple cannot check it for malicious software. This software needs to be updated. Contact the developer for more information.

However, this warning panel had three buttons: Open, Show in Finder, and Cancel. (The Open option was not present in the original warning panel.)

When I clicked Open in this panel, I received an "Emacs quit unexpectedly." window with a debug trace. Apparently the ruby script is attempting to open the Emacs-x86-64-10_14 version of Emacs on my iMac M1 (ARM64) system. Something appears to be wrong with the ruby script in my environment.

Stack trace for the failing process thread are:

Process:               Emacs-x86_64-10_14 [70691]
Path:                  /Applications/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14
Identifier:            org.gnu.Emacs
Version:               Version 27.2 (9.0)
Code Type:             X86-64 (Translated)
Parent Process:        ??? [1]
Responsible:           Emacs-x86_64-10_14 [70691]
User ID:               501

Date/Time:             2021-08-07 15:48:05.147 -0700
OS Version:            macOS 11.5 (20G71)
Report Version:        12
Anonymous UUID:        7A5C2A2B-455F-11B4-05C1-951C54F20ED1

Time Awake Since Boot: 980000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_INSTRUCTION (SIGABRT)
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   ???                                 0x00007ffe9465e8f4 ???
1   libsystem_kernel.dylib          0x00007fff203ff92e __pthread_kill + 10
2   libsystem_c.dylib               0x00007fff20312bd5 raise + 26
3   Emacs-x86_64-10_14              0x0000000102c9e6d9 terminate_due_to_signal + 153
4   Emacs-x86_64-10_14              0x0000000102c9f01b emacs_abort + 15
5   Emacs-x86_64-10_14              0x0000000102c66880 ns_term_shutdown + 80
6   Emacs-x86_64-10_14              0x0000000102b565d4 shut_down_emacs + 340
7   Emacs-x86_64-10_14              0x0000000102c9e6a6 terminate_due_to_signal + 102
8   Emacs-x86_64-10_14              0x0000000102b76e8e handle_fatal_signal + 14
9   Emacs-x86_64-10_14              0x0000000102b76f11 deliver_thread_signal + 129
10  Emacs-x86_64-10_14              0x0000000102b75969 deliver_fatal_thread_signal + 9
11  libsystem_platform.dylib        0x00007fff20473d7d _sigtramp + 29
12  ???                                 000000000000000000 0 + 0
13  Emacs-x86_64-10_14              0x0000000102c3b5c9 decode_time_components + 633
14  Emacs-x86_64-10_14              0x0000000102c3c0df decode_lisp_time + 159
15  Emacs-x86_64-10_14              0x0000000102c3d240 Ftime_convert + 32
16  Emacs-x86_64-10_14              0x0000000102be3331 funcall_subr + 257
17  Emacs-x86_64-10_14              0x0000000102be291b Ffuncall + 843
18  Emacs-x86_64-10_14              0x0000000102c25c57 exec_byte_code + 1815
19  Emacs-x86_64-10_14              0x0000000102be28b9 Ffuncall + 745
20  Emacs-x86_64-10_14              0x0000000102c25c57 exec_byte_code + 1815
21  Emacs-x86_64-10_14              0x0000000102be28b9 Ffuncall + 745
22  Emacs-x86_64-10_14              0x0000000102c25c57 exec_byte_code + 1815
23  Emacs-x86_64-10_14              0x0000000102be28b9 Ffuncall + 745
24  Emacs-x86_64-10_14              0x0000000102c25c57 exec_byte_code + 1815
25  Emacs-x86_64-10_14              0x0000000102be28b9 Ffuncall + 745
26  Emacs-x86_64-10_14              0x0000000102c25c57 exec_byte_code + 1815
27  Emacs-x86_64-10_14              0x0000000102be28b9 Ffuncall + 745
28  Emacs-x86_64-10_14              0x0000000102c25c57 exec_byte_code + 1815
29  Emacs-x86_64-10_14              0x0000000102be28b9 Ffuncall + 745
30  Emacs-x86_64-10_14              0x0000000102c25c57 exec_byte_code + 1815
31  Emacs-x86_64-10_14              0x0000000102be28b9 Ffuncall + 745
32  Emacs-x86_64-10_14              0x0000000102be2f8c call1 + 44
33  Emacs-x86_64-10_14              0x0000000102bee4c8 mapcar1 + 88
34  Emacs-x86_64-10_14              0x0000000102bee90b Fmapc + 75
35  Emacs-x86_64-10_14              0x0000000102be3331 funcall_subr + 257
36  Emacs-x86_64-10_14              0x0000000102be291b Ffuncall + 843
37  Emacs-x86_64-10_14              0x0000000102c25c57 exec_byte_code + 1815
38  Emacs-x86_64-10_14              0x0000000102be28b9 Ffuncall + 745
39  Emacs-x86_64-10_14              0x0000000102c25c57 exec_byte_code + 1815
40  Emacs-x86_64-10_14              0x0000000102be2164 apply_lambda + 356
41  Emacs-x86_64-10_14              0x0000000102bde69f eval_sub + 783
42  Emacs-x86_64-10_14              0x0000000102be1e9a Feval + 106
43  Emacs-x86_64-10_14              0x0000000102be0f77 internal_condition_case + 263
44  Emacs-x86_64-10_14              0x0000000102b6a72d top_level_1 + 45
45  Emacs-x86_64-10_14              0x0000000102be079b internal_catch + 267
46  Emacs-x86_64-10_14              0x0000000102c9ea96 command_loop.cold.1 + 54
47  Emacs-x86_64-10_14              0x0000000102b59633 command_loop + 131
48  Emacs-x86_64-10_14              0x0000000102b59563 recursive_edit_1 + 115
49  Emacs-x86_64-10_14              0x0000000102b597bb Frecursive_edit + 347
50  Emacs-x86_64-10_14              0x0000000102b5834c main + 7436
51  libdyld.dylib                       0x00007fff20449f3d start + 1

If I open the Emacs.app package in the Finder, and double-click on Contents/macOS/Emacs_arm64-11_2, that Emacs file is opened in a Terminal.app window which contains three lines:

Last login: Sat Aug  7 15:40:43 on ttys001
/Applications/Emacs.app/Contents/MacOS/Emacs-arm64-11_2 ; exit;                                                                 
~ => /Applications/Emacs.app/Contents/MacOS/Emacs-arm64-11_2 ; exit;

The normal Emacs window opens in front of that Terminal window. Emacs appears to function correctly in that window.

The Terminal.app window remains open until I quit out of Emacs (via ^X^C, or Cmd-Q, or just close the Emacs window via red X button at top of window).

Hope this debugging information helps you to understand what's going wrong.

[elvey]

Works for me on M1 after the steps adamcstephens gives of course.

(This bug is annoying though; I may try to completely fix this bug by getting a developer account so I can sign it. )

GNU Emacs 27.2 (build 1, arm-apple-darwin20.3.0, NS appkit-2022.30 Version 11.2.3 (Build 20D91))

Possibly relevant: [I have NOT installed Rosetta 2. I deleted the x86 binaries (Contents/MacOS/Emacs/*x86*) and Contents/Resources/lisp/leim folder - not needed; does break the code signature.)]

[GaryDixon]

I am currently running macOS 11.5.2 and do have Rosetta 2 downloaded since my migration to that platform did load some X86 applications.

In earlier tests, I had been running with the latest version of Emacs recommended on the emacsformacosx.com http://emacsformacosx.com/ web site: Emacs Version 27.2-2: the version that gets downloaded as: Emacs-27.2-2-universal.dmg

Based upon your email below, I also tried downloading the Emacs-27.2-1-universal.dmg. I experienced the same error panel: “Emacs.app” can’t be opened because Apple cannot check it for malicious software. This software needs to be updated. Contact the developer for more information.

If I open the package contents, and double-click on Contents/MacOS/Emacs-arm64-11_2 file, I get a security alert panel saying my settings don’t permit opening unsigned software downloaded from the web. If I open System_Preferences > Security & Privacy > General panel, I see a message at bottom of panel saying: “Emacs.app” was blocked from use because it is not from an identified developer. (Open Anyway)

If I click the (Open Anyway) button in that panel, I get another panel saying: “Emacs.app” can’t be opened because Apple cannot check it for malicious software. … but this panel has a (Open) button.

If I click that Open button, I get the Problem Report for Emacs panel showing a stack trace saying it really tried to run X86_64 version of Emacs under Rosetta 2 (which I do have downloaded on my system).

Process: Emacs-x86_64-10_14 [11932] Path: /Applications/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14 Identifier: org.gnu.Emacs Version: Version 27.2 (9.0) Code Type: X86-64 (Translated) Parent Process: ??? [1] Responsible: Emacs-x86_64-10_14 [11932] User ID: 501

Date/Time: 2021-08-16 06:39:29.918 -0700 OS Version: macOS 11.5.2 (20G95) Report Version: 12 Anonymous UUID: 7A5C2A2B-455F-11B4-05C1-951C54F20ED1

Time Awake Since Boot: 3900 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_INSTRUCTION (SIGABRT) Exception Codes: 0x0000000000000001, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 0x00007ffe9460e8f4 ??? 1 libsystem_kernel.dylib 0x00007fff203a792e __pthread_kill + 10 2 libsystem_c.dylib 0x00007fff202babd5 raise + 26 3 Emacs-x86_64-10_14 0x000000010492c6d9 terminate_due_to_signal + 153 4 Emacs-x86_64-10_14 0x000000010492d01b emacs_abort + 15 5 Emacs-x86_64-10_14 0x00000001048f4880 ns_term_shutdown + 80 6 Emacs-x86_64-10_14 0x00000001047e45d4 shut_down_emacs + 340 7 Emacs-x86_64-10_14 0x000000010492c6a6 terminate_due_to_signal + 102 8 Emacs-x86_64-10_14 0x0000000104804e8e handle_fatal_signal + 14 9 Emacs-x86_64-10_14 0x0000000104804f11 deliver_thread_signal + 129 10 Emacs-x86_64-10_14 0x0000000104803969 deliver_fatal_thread_signal + 9 11 libsystem_platform.dylib 0x00007fff2041bd7d _sigtramp + 29 12 ??? 000000000000000000 0 + 0 13 Emacs-x86_64-10_14 0x00000001048c95c9 decode_time_components + 633 14 Emacs-x86_64-10_14 0x00000001048ca0df decode_lisp_time + 159 15 Emacs-x86_64-10_14 0x00000001048cb240 Ftime_convert + 32 16 Emacs-x86_64-10_14 0x0000000104871331 funcall_subr + 257 17 Emacs-x86_64-10_14 0x000000010487091b Ffuncall + 843 18 Emacs-x86_64-10_14 0x00000001048b3c57 exec_byte_code + 1815 19 Emacs-x86_64-10_14 0x00000001048708b9 Ffuncall + 745 20 Emacs-x86_64-10_14 0x00000001048b3c57 exec_byte_code + 1815 21 Emacs-x86_64-10_14 0x00000001048708b9 Ffuncall + 745 22 Emacs-x86_64-10_14 0x00000001048b3c57 exec_byte_code + 1815 23 Emacs-x86_64-10_14 0x00000001048708b9 Ffuncall + 745 24 Emacs-x86_64-10_14 0x00000001048b3c57 exec_byte_code + 1815 25 Emacs-x86_64-10_14 0x00000001048708b9 Ffuncall + 745 26 Emacs-x86_64-10_14 0x00000001048b3c57 exec_byte_code + 1815 27 Emacs-x86_64-10_14 0x00000001048708b9 Ffuncall + 745 28 Emacs-x86_64-10_14 0x00000001048b3c57 exec_byte_code + 1815 29 Emacs-x86_64-10_14 0x00000001048708b9 Ffuncall + 745 30 Emacs-x86_64-10_14 0x00000001048b3c57 exec_byte_code + 1815 31 Emacs-x86_64-10_14 0x00000001048708b9 Ffuncall + 745 32 Emacs-x86_64-10_14 0x0000000104870f8c call1 + 44 33 Emacs-x86_64-10_14 0x000000010487c4c8 mapcar1 + 88 34 Emacs-x86_64-10_14 0x000000010487c90b Fmapc + 75 35 Emacs-x86_64-10_14 0x0000000104871331 funcall_subr + 257 36 Emacs-x86_64-10_14 0x000000010487091b Ffuncall + 843 37 Emacs-x86_64-10_14 0x00000001048b3c57 exec_byte_code + 1815 38 Emacs-x86_64-10_14 0x00000001048708b9 Ffuncall + 745 39 Emacs-x86_64-10_14 0x00000001048b3c57 exec_byte_code + 1815 40 Emacs-x86_64-10_14 0x0000000104870164 apply_lambda + 356 41 Emacs-x86_64-10_14 0x000000010486c69f eval_sub + 783 42 Emacs-x86_64-10_14 0x000000010486fe9a Feval + 106 43 Emacs-x86_64-10_14 0x000000010486ef77 internal_condition_case + 263 44 Emacs-x86_64-10_14 0x00000001047f872d top_level_1 + 45 45 Emacs-x86_64-10_14 0x000000010486e79b internal_catch + 267 46 Emacs-x86_64-10_14 0x000000010492ca96 command_loop.cold.1 + 54 47 Emacs-x86_64-10_14 0x00000001047e7633 command_loop + 131 48 Emacs-x86_64-10_14 0x00000001047e7563 recursive_edit_1 + 115 49 Emacs-x86_64-10_14 0x00000001047e77bb Frecursive_edit + 347 50 Emacs-x86_64-10_14 0x00000001047e634c main + 7436 51 libdyld.dylib 0x00007fff203f1f3d start + 1

Thread 1:: com.apple.rosetta.exceptionserver ...

I also tried cases where I removed the Contents/Resources/lisp/leim folder, and all of the Contents/MacOS/Emacs items/folders having X86 in their name. Clicking on the /Applications/Emacs.app then reported that the app was damaged and should be moved to the Trash folder. Instead, I opened the package contents and tried to double-click on Contents/MacOS/Emacs and …/Emacs_arm64-11_2. Neither of these two attempts opened anything.

I think things might work more correctly if you could code-sign the application package. If your package used “fat file” binaries for Emacs and its various library files, it might work more smoothly under macOS 11. [“fat file” binaries can be created using the lipo command to merge X86 and ARM64 objects into a single binary file.] However, I have no idea what problems this might cause when trying to support earlier macOS versions.

Meanwhile, the X86 version of emacs (downloaded in 2020) does work OK under Rosetta 2. It’s a little slower than a native arm64 version, but reasonable to use until the above problems can be resolved.

I also tried downloading, building and running the Homebrew version of emacs, for use when I invoke emacs in a Terminal.app window. That works great in the terminal-window environment, but lacks the app integration of your emacsformacosx product.

Gary Dixon

On Aug 15, 2021, at 11:50 PM, elvey @.***> wrote:

Works for me on M1. This is annoying though; I may try to completely fix this bug by getting a developer account so I can sign it.

GNU Emacs 27.2 (build 1, arm-apple-darwin20.3.0, NS appkit-2022.30 Version 11.2.3 (Build 20D91))

Possibly relevant: [I have NOT installed Rosetta 2. I deleted the x86 binaries (Contents/MacOS/Emacs/x86) and Contents/Resources/lisp/leim folder)]

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/caldwell/build-emacs/issues/109#issuecomment-899266314, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACMKKLIMDONBYZ67ADCBFALT5CYKTANCNFSM46342D7Q. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email.

[elvey]

You downloaded a new version, so you havre to go through the steps adamcstephens gave, again (w/o opening the package contents). https://emacsformacosx.com/download/emacs-builds/Emacs-27.2-2-universal.dmg is what I'm using.

[GaryDixon]

I found the Emacs package referred to my adamcstephensp reply: GNU Emacs 27.2 (build 1, arm-apple-darwin20.3.0, NS appkit-2022.30 Version 11.2.3 (Build 20D91)) of 2021-03-27

When that package is installed in Applications directory, I get the EXC_BAD_INSTRUCTION (SIGABRT) error (described in earlier message) when invoking Emacs (by double-clicking on Emacs.app icon, or attempting to open Emacs icon from the dock).

However, when I drag this Applications/Emacs.app folder into a subdirectory (I originally called it /Applications/BAD_APPS, but have renamed this to /Applications/M1_APPS), I can invoke that same Emacs.app icon and it works correctly without deleting the X86 binaries, etc.

I verified that when it is running, it is the ARM64 binary that is open and executing (by inspecting the open files used by the running Emacs process shown in the Activity Monitor). It shows the following Open Files and Ports:

cwd
/Users/garydixon
txt
/Applications/M1_Apps/Emacs.app/Contents/MacOS/Emacs-arm64-11_2
txt
/Applications/M1_Apps/Emacs.app/Contents/MacOS/lib-arm64-11_2/libgnutls.30.dylib
txt
/Applications/M1_Apps/Emacs.app/Contents/MacOS/lib-arm64-11_2/libjansson.4.dylib
txt
/Library/Preferences/Logging/.plist-cache.fKalPmEh
txt
/Applications/M1_Apps/Emacs.app/Contents/MacOS/lib-arm64-11_2/libgmp.10.dylib
txt
/Applications/M1_Apps/Emacs.app/Contents/MacOS/lib-arm64-11_2/libintl.8.dylib
txt
/Applications/M1_Apps/Emacs.app/Contents/MacOS/lib-arm64-11_2/libnettle.8.dylib
txt
/usr/lib/dyld
txt
/Applications/M1_Apps/Emacs.app/Contents/MacOS/lib-arm64-11_2/libhogweed.6.dylib
txt
/Applications/M1_Apps/Emacs.app/Contents/MacOS/Emacs-arm64-11_2.pdmp
txt
/usr/share/icu/icudt66l.dat
txt
/private/var/db/timezone/tz/2021a.1.0/icutz/icutz44l.dat
txt
/private/var/db/analyticsd/events.whitelist
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/SystemAppearance.car
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/DarkAqua.car
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/FauxVibrantDark.car
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/VibrantDark.car
txt
/System/Library/Fonts/SFNS.ttf
txt
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/Extras2.rsrc
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/Assets.car
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/Aqua.car
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/VibrantLight.car
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/Graphite.car
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/FauxVibrantLight.car
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/FauxVibrantLightGraphite.car
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/VibrantLightGraphite.car
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/AquaAX.car
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/GraphiteAX.car
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/VibrantLightAX.car
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/VibrantLightGraphiteAX.car
txt
/System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/DarkGraphite.car
txt
/usr/lib/libobjc-trampolines.dylib
txt
/System/Library/Caches/com.apple.IntlDataCache.le.kbdx
txt
/System/Library/Keyboard Layouts/AppleKeyboardLayouts.bundle/Contents/Resources/AppleKeyboardLayouts-L.dat
txt
/System/Library/Fonts/Menlo.ttc
txt
/System/Library/CoreServices/CoreGlyphs.bundle/Contents/Resources/Assets.car
txt
/System/Library/Fonts/Helvetica.ttc
txt
/System/Library/Fonts/Courier.dfont
txt
/Applications/M1_Apps/Emacs.app/Contents/Resources/etc/images/splash.png
txt
/private/var/folders/hl/rsv8d7551vb8lmx44qbns8gh0000gn/C/org.gnu.Emacs/com.apple.metal/16777235_322/functions.data
txt
/System/Library/Extensions/AGXMetal13_3.bundle/Contents/MacOS/AGXMetal13_3
txt
/System/Library/Extensions/AGXMetal13_3.bundle/Contents/Resources/ds.g13g
txt
/private/var/folders/hl/rsv8d7551vb8lmx44qbns8gh0000gn/C/org.gnu.Emacs/com.apple.metal/31001/libraries.data
0
/dev/null
1
/dev/null
2
/dev/null
3
->0x7296b1e0c4ba7453
4
->0xef9b539c0ab58aaf
5
/System/Library/Frameworks/CoreImage.framework/Versions/A/Resources/ci_stdlib.metallib
6
/private/var/folders/hl/rsv8d7551vb8lmx44qbns8gh0000gn/C/org.gnu.Emacs/com.apple.metal/16777235_322/functions.data
7
/private/var/folders/hl/rsv8d7551vb8lmx44qbns8gh0000gn/C/org.gnu.Emacs/com.apple.metal/16777235_322/functions.list
8
/System/Library/Frameworks/CoreImage.framework/Versions/A/Resources/ci_filters.metallib
9
/Users/garydixon/Library/Saved Application State/org.gnu.Emacs.savedState/window_1.data
10
/private/var/folders/hl/rsv8d7551vb8lmx44qbns8gh0000gn/C/org.gnu.Emacs/com.apple.metal/31001/libraries.data
11
/private/var/folders/hl/rsv8d7551vb8lmx44qbns8gh0000gn/C/org.gnu.Emacs/com.apple.metal/31001/libraries.list
12
/Users/garydixon/Library/Saved Application State/org.gnu.Emacs.savedState/data.data
13
/Users/garydixon/Library/Saved Application State/org.gnu.Emacs.savedState/windows.plist

So perhaps the problem is in the Emacs script (Ruby code) which is selecting which version of the Emacs binary to run. I'm not familiar with the Ruby language, so have not tried to figure out whether/why this script might behave differently if Emacs.app it placed directly in /Applications versus placement in a subdirectory of /Applications.

But now I have an M1-native version of emacsformacos that is working correctly, and doesn't require any other modification than moving the app to a subdir of /Applications.

[elvey]

Interesting / strange. Glad you got it working.

Like you, I'm switching from emacs I installed with homebrew back to the GUI version I used on macOS on x86. Just noticed that I didn't have access to ~/Documents. Granted it (Emacs.app) full disk access in Security and Privacy, restarted Emacs and I still didn't! But I do IF/ONCE I access it thru the File menu (File..Open File...in Documents) rather than through usual means (C-x C-f ...). After that it seems to work. Semi-apologies for going OT in OP's bug, but seems likely to be relevant to OP. . Update: Oh, and I revoked full disk access (and restarted Emacs.app) and I can still open ~/Documents. BUG + WORKAROUND.

[ADDENDUM; 17 Oct: above issue was in the same build thynus says gives "No problem installing, writing files", just below." (GNU Emacs 27.2 (build 1, arm-apple-darwin20.3.0, NS appkit-2022.30 Version 11.2.3 (Build 20D91))

@thynus does NOT indicate whether the (C-x C-f ~/Documents ...) issue was reproducible. I suppose a separate ticket could be opened if this is closed...]

[thynus]

Downloaded Emacs 27.2 Universal binary from emacsforosx on m1 arm mac with 11.6 big sur. GNU Emacs 27.2 (build 1, arm-apple-darwin20.3.0, NS appkit-2022.30 Version 11.2.3 (Build 20D91)) of 2021-03-27

No problem installing, writing files. Cannot reproduce this problem.

see: https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac or: System Preferences > Security and Privacy Allow apps downloaded from: x App store and identified developers

Update: C-x C-f ~/Documents/myText.txt successfully created, added text and saved files as usual.

OP stated:

But now I have an M1-native version of emacsformacos that is working correctly, and doesn't require any other modification than moving the app to a subdir of /Applications.

Please close the issue.

[jdhuntington]

I've had the exact same experience as @GaryDixon , including the wrong binary launching and the stack trace. Creating a subdirectory in /Applications does appear to fix my issue, but the standard location of Emacs.app does not work for me even with the latest download.

Thanks @GaryDixon for a workaround though!

[caldwell]

I recently worked around the issue that caused emacs to crash on M1 macs with an Illegal Instruction. commit 0c8cb9545c607d2a368a10a23a4d637d6cb7267e has the fix. Nightlies after 2021-10-26 should have that change (unfortunately the last few days the git master branch has been broken, so nightlies haven't built). I'd love to know if this fixes the crashing problem you are seeing. If so, I'll probably rebuild an updated release emacs 27.2 with the fix.

[thynus]

Hello,

This seemed to point to the problem: https://betterprogramming.pub/ruby-on-apple-silicon-m1-macs-fb159849b2f5

My default ruby on Big Sur 11.6 on an arm mac is: ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.arm64e-darwin20]

Thanks

[GaryDixon]

David, I’d be happy to test your change. It is not obvious to me how that should be done.

If I click on the commit link in your email below, it opens a window showing the 1 change to launch.rb, but I don’t see an Emacs-27.2-n-universal.dmg file built with that change. And you have said the nightlies have been broken (though I do see some claiming to have been built after 2021-10-26). If I download the latest of those nightly builds (for example: Emacs-2021-10-30_00-09-15-c3499b8…-universal.dmg https://emacsformacosx.com/emacs-builds/Emacs-2021-10-30_00-09-15-c3499b8ddc357544a58917bfd3846f88caf5d97c-universal.dmg), will it include the fix you want tested?

On the other hand, if I open my Applications/M1_Apps/Emacs.app/Contents/macOS directory, I can see the Emacs file that contains the launch.rb contents shown in the commit. Is it safe for me to just copy the added lines from your commit 0c8cb95 into the appropriate location of my Emacs file, then move my Applications/M1_Apps/Emacs directory to Applications/Emacs, then try to invoke that Emacs?

Could you provide instructions on exactly how you want me to test this latest fix? Notice that I think I am running the nightly build from June 17 (though I am not certain how to confirm that). I had tried several different Emacs versions in August, then found the one I downloaded in mid-June worked if I moved it to a subdirectory below Applications (IIRC).

Thanks, Gary Dixon

On Nov 4, 2021, at 2:43 PM, David Caldwell @.***> wrote:

I recently worked around the issue that caused emacs to crash on M1 macs with an Illegal Instruction. commit 0c8cb95 https://github.com/caldwell/build-emacs/commit/0c8cb9545c607d2a368a10a23a4d637d6cb7267e has the fix. Nightlies after 2021-10-26 should have that change (unfortunately the last few days the git master branch has been broken, so nightlies haven't built). I'd love to know if this fixes the crashing problem you are seeing. If so, I'll probably rebuild an updated release emacs 27.2 with the fix.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/caldwell/build-emacs/issues/109#issuecomment-961452941, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACMKKLKXLKQNICN3O63C3ADUKMEB3ANCNFSM46342D7Q. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[caldwell]

@GaryDixon Sorry, yeah I wasn't super clear. The 2020-10-27, 2020-10-28, 2020-10-29, 2020-10-30 nightly builds should all have the fix in them.

However you were making it crash before, try the same thing with one of those builds. Ideally it won't crash :-).

@thynus, that's interesting but I'm not sure it's the same issue—I think it's the opposite? In the Emacs case if you launch from the command line with

arch -arm64 /Applications/Emacs.app/Contents/MacOS/Emacs

then it works, but

arch -x86_64 /Applications/Emacs.app/Contents/MacOS/Emacs

causes the Illegal instruction.

[GaryDixon]

David,

I downloaded the latest nightly build: Emacs-2021-10-30_00-09-15-c3499b8…-universal.dmg https://emacsformacosx.com/emacs-builds/Emacs-2021-10-30_00-09-15-c3499b8ddc357544a58917bfd3846f88caf5d97c-universal.dmg

I double-clicked that .dmg file to open the installer, and dragged the Emacs app onto the Applications folder link. It installed Emacs.app into my Applications directory.

I double-clicked that Applications/Emacs.app icon, got the same panel about macOS not wanting to open an unsigned app downloaded from the web. I opened my System Preference >> Security & Privacy panel, and saw a report about failure to open that Emacs.app. I clicked the Open Anyway button, and it successfully opened the Emacs application with no crash.

Closed Emacs then reopened it… and got no warning panel about “opening unsigned software" after having successfully opened it once.

Opened the Activity Monitor and selected the open Emacs app. Got info for its files, which included: /Applications/Emacs.app/Contents/MacOS/Emacs-arm64-12 txt /Applications/Emacs.app/Contents/MacOS/lib-arm64-12/libjansson.4.dylib txt /Applications/Emacs.app/Contents/MacOS/lib-arm64-12/libintl.8.dylib

It looks like it is definitely using the arm64 versions from the universal build. So this version appears to resolve the problem I originally reported.

Thanks for your repair efforts.

I’ll continue running with this nightly build for now.

Gary Dixon

On Nov 4, 2021, at 3:52 PM, David Caldwell @.***> wrote:

@GaryDixon https://github.com/GaryDixon Sorry, yeah I wasn't super clear. The 2020-10-27, 2020-10-28, 2020-10-29, 2020-10-30 nightly builds should all have the fix in them.

However you were making it crash before, try the same thing with one of those builds. Ideally it won't crash :-).

@thynus https://github.com/thynus, that's interesting but I'm not sure it's the same issue—I think it's the opposite? In the Emacs case if you launch from the command line with

arch -arm64 /Applications/Emacs.app/Contents/MacOS/Emacs then it works, but

arch -x86_64 /Applications/Emacs.app/Contents/MacOS/Emacs causes the Illegal instruction.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/caldwell/build-emacs/issues/109#issuecomment-961491857, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACMKKLJLAAR53SENHAN6SHTUKMMCPANCNFSM46342D7Q. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[elvey]

Cool. Looks like that fixed it.

(FYI, I think @thynus was on the right track. If I'm not mistaken, this helps explain why your fix works : I noticed that for me on M1.

 % mdfind -0 rbconfig.rb | xargs -0 grep "_cpu"
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin21/rbconfig.rb:  CONFIG["target_cpu"] = "universal"
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin21/rbconfig.rb:  CONFIG["host_cpu"] = "x86_64"
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin21/rbconfig.rb:  CONFIG["build_cpu"] = "x86_64"

[Above is 12.1 Beta (21C5021h). Below is 11.6?]

/Volumes/M1 SSD/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin20/rbconfig.rb:  CONFIG["target_cpu"] = "universal"
/Volumes/M1 SSD/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin20/rbconfig.rb:  CONFIG["host_cpu"] = "x86_64"
/Volumes/M1 SSD/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin20/rbconfig.rb:  CONFIG["build_cpu"] = "x86_64"
/Volumes/M1 SSD/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin20/rbconfig.rb:  CONFIG["target_cpu"] = "universal"
/Volumes/M1 SSD/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin20/rbconfig.rb:  CONFIG["host_cpu"] = "x86_64"
/Volumes/M1 SSD/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin20/rbconfig.rb:  CONFIG["build_cpu"] = "x86_64"
/Volumes/M1 SSD/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin19/rbconfig.rb:  CONFIG["target_cpu"] = "universal"
/Volumes/M1 SSD/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin19/rbconfig.rb:  CONFIG["host_cpu"] = "x86_64"
/Volumes/M1 SSD/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin19/rbconfig.rb:  CONFIG["build_cpu"] = "x86_64"

It seems to me the misconfiguration of Ruby is making EmacsX86 code run.)

[Edit--P.S. So the output of arch -arch x86_64 /usr/bin/uname -m on M1, with Rosetta installed is ...? (I haven't installed it. I get arch: posix_spawnp: /usr/bin/uname: Bad CPU type in executable ). Oh, and belowyou mean line 42 (was 41).]

[caldwell]

Here's another reason I think the Ruby thing is a red herring in this case: check out line 41 of the launcher script: it doesn't trust anything ruby says and shells out to uname to figure out the architecture. I don't think Ruby can affect that.

As far as I understand it, that rbconfig stuff is all about how Ruby finds and loads gem module shared libs, which should not be happening here.

[GaryDixon]

As it happens I just updated my system to macOS 12.0.1. I had been running 11.6.5 (IIRC, or at least some Big Sur version). So perhaps the issue was fixed by my upgrade to macOS Monterey rather than by your change. Just raising the possibility…

To distinguish the two possibilities, I moved the latest nightly build Emacs to Applications/M1_Apps directory, then moved the earlier version of Emacs.app from Trash can to Applications directory. Now that earlier version opens correctly even while installed directly in Applications dir.

This suggests the problem was Apple’s rather an in Emacs.app.

Gary Dixon

On Nov 4, 2021, at 4:55 PM, elvey @.***> wrote:

Cool. Looks like that fixed it.

(FYI, I think @thynus https://github.com/thynus was on the right track. I noticed that for me on M1). If I'm not mistaken, this helps explain why your fix works :

% mdfind -0 rbconfig.rb | xargs -0 grep "_cpu" /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin21/rbconfig.rb: CONFIG["target_cpu"] = "universal" /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin21/rbconfig.rb: CONFIG["host_cpu"] = "x86_64" /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin21/rbconfig.rb: CONFIG["build_cpu"] = "x86_64" [Above is 12.1 Beta (21C5021h). Below is 11.6?]

/Volumes/M1 SSD/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin20/rbconfig.rb: CONFIG["target_cpu"] = "universal" /Volumes/M1 SSD/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin20/rbconfig.rb: CONFIG["host_cpu"] = "x86_64" /Volumes/M1 SSD/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin20/rbconfig.rb: CONFIG["build_cpu"] = "x86_64" /Volumes/M1 SSD/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin20/rbconfig.rb: CONFIG["target_cpu"] = "universal" /Volumes/M1 SSD/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin20/rbconfig.rb: CONFIG["host_cpu"] = "x86_64" /Volumes/M1 SSD/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin20/rbconfig.rb: CONFIG["build_cpu"] = "x86_64" /Volumes/M1 SSD/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin19/rbconfig.rb: CONFIG["target_cpu"] = "universal" /Volumes/M1 SSD/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin19/rbconfig.rb: CONFIG["host_cpu"] = "x86_64" /Volumes/M1 SSD/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin19/rbconfig.rb: CONFIG["build_cpu"] = "x86_64"

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/caldwell/build-emacs/issues/109#issuecomment-961521134, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACMKKLPUDTN57PXNHFSIQS3UKMTO7ANCNFSM46342D7Q. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[caldwell]

Select the Emacs.app in Finder and do "Get Info" from the file menu (or right click or "command-I"). There's checkbox in the "General" section labelled "Open using Rosetta". On the 27.2-2 Emacs, if that checkbox is set, you will get the Illegal Instruction crash. On the new Nightlies, they should work regardless of the checkbox.

I think what might be happening is that Apple tries to remember (in an out of band cache) which Applications are arm native or not and replacing Emacs with a native version is confusing their cache somehow. But I don't really have any insight, it just seems that something like that is happening. It kind of explains why moving stuff around like that might magically fix things, and why some people on M1s see this problem but not everyone…

[GaryDixon]

The version of Emacs.app I now run (the latest nightly build) did have the “Open using Rosetta” flag on. I turned it off and was still able to open/use that Emacs.app. It isn’t clear to me how that flag got turned on.

On Nov 4, 2021, at 6:03 PM, David Caldwell @.***> wrote:

Select the Emacs.app in Finder and do "Get Info" from the file menu (or right click or "command-I"). There's checkbox in the "General" section labelled "Open using Rosetta". On the 27.2-2 Emacs, if that checkbox is set, you will get the Illegal Instruction crash. On the new Nightlies, they should work regardless of the checkbox.

I think what might be happening is that Apple tries to remember (in an out of band cache) which Applications are arm native or not and replacing Emacs with a native version is confusing their cache somehow. But I don't really have any insight, it just seems that something like that is happening. It kind of explains why moving stuff around like that might magically fix things, and why some people on M1s see this problem but not everyone…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/caldwell/build-emacs/issues/109#issuecomment-961548349, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACMKKLIZ5Z74NZTL7UKGXMTUKM3NTANCNFSM46342D7Q. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[caldwell]

I believe the original problem is fixed at this point.

[njr0]

I just had this issue after building Emacs 29.0.1 on Mac OS Ventura (13.1).

None of the fixes above worked, but removing the com.apple.quarantine tag did:

xattr -d com.apple.quarantine Emacs.app

Do this at your peril!