build-emacs-for-macos
build-emacs-for-macos copied to clipboard
jimeh
`libgccjit.so`: error invoking gcc driver
Hi there! I want to say huge thanks for this project, I've been using it since December on my m1 pro to periodically build native-comp emacs apps. Just recently, I started to get issues with the new builds when actually running my built emacs app using libgccjit, here is how I build it (using the last good commit hash for demonstration purposes):
./build-emacs-for-macos -j8 --native-comp --native-full-aot --git-sha 7be75f17e79b547dc03e26e3980d4ce75bfa668d master
However, when actually launching emacs, I get the following error:
Error (use-package): lsp-pyright/:catch: Native compiler error: (lambda (arg409 &optional arg410 arg411) (let ((f #'describe-buffer-bindings)) (funcall f arg409 arg410 arg411))), "Compiling /Users/thecsw/.emacs.d/eln-cache/28.0.50-a0772fdf/subr--trampoline-64657363726962652d6275666665722d62696e64696e6773_describe_buffer_bindings_0.eln...
ld: library not found for -lgcc_s.1.1
libgccjit.so: error: error invoking gcc driver
Debugger entered--Lisp error: (native-ice \"failed to compile\" \"/Users/thecsw/.emacs.d/eln-cache/28.0.50-a0772fdf/...\" \"error invoking gcc driver\")
comp--compile-ctxt-to-file(\"/Users/thecsw/.emacs.d/eln-cache/28.0.50-a0772fdf/...\")
comp-compile-ctxt-to-file(\"/Users/thecsw/.emacs.d/eln-cache/28.0.50-a0772fdf/...\")
comp-final1()
load-with-code-conversion(\"/private/var/folders/7d/4s6h974n48l1l3v09q2fz9mc00...\" \"/private/var/folders/7d/4s6h974n48l1l3v09q2fz9mc00...\" nil t)
command-line-1((\"-l\" \"/var/folders/7d/4s6h974n48l1l3v09q2fz9mc0000gn/T/e...\"))
command-line()
normal-top-level()
" Disable showing Disable logging
Warning (initialization): An error occurred while loading ‘/Users/thecsw/.emacs’:
Native compiler error: (lambda (arg485 &optional arg486) (let ((f #'delete-file)) (funcall f arg485 arg486))), Compiling /Users/thecsw/.emacs.d/eln-cache/28.0.50-a0772fdf/subr--trampoline-64656c6574652d66696c65_delete_file_0.eln...
ld: library not found for -lgcc_s.1.1
libgccjit.so: error: error invoking gcc driver
Debugger entered--Lisp error: (native-ice "failed to compile" "/Users/thecsw/.emacs.d/eln-cache/28.0.50-a0772fdf/..." "error invoking gcc driver")
comp--compile-ctxt-to-file("/Users/thecsw/.emacs.d/eln-cache/28.0.50-a0772fdf/...")
comp-compile-ctxt-to-file("/Users/thecsw/.emacs.d/eln-cache/28.0.50-a0772fdf/...")
comp-final1()
load-with-code-conversion("/private/var/folders/7d/4s6h974n48l1l3v09q2fz9mc00..." "/private/var/folders/7d/4s6h974n48l1l3v09q2fz9mc00..." nil t)
command-line-1(("-l" "/var/folders/7d/4s6h974n48l1l3v09q2fz9mc0000gn/T/e..."))
command-line()
normal-top-level()
To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file. Start Emacs with
the ‘--debug-init’ option to view a complete error backtrace. Disable showing Disable logging
Warning (comp): libgccjit.so: error: error invoking gcc driver Disable showing Disable logging
Warning (comp): /Users/thecsw/.emacs.d/elpa/s-20210616.619/s.el: Error: Internal native compiler error failed to compile Disable showing Disable logging
Warning (comp): libgccjit.so: error: error invoking gcc driver Disable showing Disable logging
Warning (comp): /Users/thecsw/.emacs.d/elpa/f-20210624.1103/f.el: Error: Internal native compiler error failed to compile Disable showing Disable logging
Warning (comp): libgccjit.so: error: error invoking gcc driver Disable showing Disable logging
Warning (comp): /Users/thecsw/.emacs.d/elpa/markdown-mode-20210616.122/markdown-mode.el: Error: Internal native compiler error failed to compile Disable showing Disable logging
Warning (comp): libgccjit.so: error: error invoking gcc driver Disable showing Disable logging
Warning (comp): /Users/thecsw/.emacs.d/elpa/lsp-mode-20210630.1507/lsp-protocol.el: Error: Internal native compiler error failed to compile Disable showing Disable logging
Warning (comp): lsp-mode.el:50:1: Warning: Package cl is deprecated Disable showing Disable logging
Warning (comp): libgccjit.so: error: error invoking gcc driver Disable showing Disable logging
Warning (comp): /Users/thecsw/.emacs.d/elpa/lsp-mode-20210630.1507/lsp-mode.el: Error: Internal native compiler error failed to compile Disable showing Disable logging
Warning (comp): libgccjit.so: error: error invoking gcc driver Disable showing Disable logging
Warning (comp): /Users/thecsw/.emacs.d/elpa/company-20210618.2105/company.el: Error: Internal native compiler error failed to compile Disable showing Disable logging
...
(goes on)
For some reason, even though my compiler built emacs with libgccjit, when emacs itself tries to compile the package into native .eln, something happens with the gcc driver.
By any chance anyone has encountered a similar error?
Thank you
Update: Forgot to mention that the build itself is finishing without errors. This has been built for arm64, uname -m returns arm64. However, if I switch to x86_64 using rosetta, the error is the same as the above.
I thought of attaching the screenshot of emacs. So the .emacs is read correctly, it's the actual async compilation. Here is the warning buffer. Thanks!
Interesting, sounds like something has gone wrong with the embedded gcc in the app bundle as it can’t find a gcc library.
Can you a couple of things to attempt to narrow down the cause of the issue?
- Launch Emacs from a terminal:
/path/to/Emacs.app/Contents/MacOS/Emacs - Try the original Emacs.app from before the build script embeds anything into it. You can find it under
sources/**/nextstep/Emacs.app. Just make sure you’re using the correct sources directory for the commit sha in question. This app bundle is not very portable as it depends on dozens of homebrew packages being installed, and homebrew package updates might break the app too.
For each, test if native compilation works, and also M-x describe-variable RET process-environment and look for the value of LIBRARY_PATH, it should match up with the paths to gcc within the Emacs.app bundle.
@jimeh Thanks for the reply!
Launching emacs build from a terminal with ./sources/emacs-mirror-emacs-ed15f39/nextstep/Emacs.app/Contents/MacOS/Emac launches emacs and the native comp with arm is actually working!
So I moved Emacs.app from nextstep into my Applications directory and it's just working now?
I don't have LIBRARY_PATH env variable when running M-x describe-variable RET process-environment
Yes, the .app from the nextstep folder should work fine. But it's not very self-contained and depends on dozens of homebrew formula being on the system, to the point upgrades to homebrew might break the Emacs.app, in which case you'd need to build a new one.
The only difference in the final output .app is that various shared libraries have been bundled into the .app, including GCC and libgccjit which are needed for native-comp. This is to try and make the app bundle as self-contained as possible.
As for LIBRARY_PATH it's actually set the first time native comp triggers a compile. So it's possible that it's not set if nothing has been native compiled yet in the current Emacs session.
I'm curious though why this is happening to you, cause it's not an issue on x86_64 builds at the moment. Annoyingly I don't have access to a M1 machine myself yet to test with, and GitHub Actions doesn't have any M1-based runners yet either.
The only obvious thing I can think of, is that your clone of build-emacs-for-macos is out of date, cause I've pushed quite a lot of changes the last few days around this area thanks to recent changes in Emacs' master branch.
I see, @jimeh! Indeed, odd. Uncompressing the built .app in ./builds and running it crashes with a signature error:
Process: Emacs [58096]
Path: /Users/USER/*/Emacs.app/Contents/MacOS/Emacs
Identifier: org.gnu.Emacs
Version: ???
Code Type: ARM-64 (Native)
Parent Process: ??? [1]
Responsible: Emacs [58096]
User ID: 501
Date/Time: 2021-07-04 13:40:42.306 -0500
OS Version: macOS 11.4 (20F71)
Report Version: 12
Anonymous UUID: 7DD1FBD5-7B6B-A9C8-BC25-7F013EA67539
Sleep/Wake UUID: 1FE00A65-7F22-44C4-9928-55E2055E7FA6
Time Awake Since Boot: 100000 seconds
Time Since Wake: 5400 seconds
System Integrity Protection: enabled
Crashed Thread: Unknown
Exception Type: EXC_BAD_ACCESS (Code Signature Invalid)
Exception Codes: 0x0000000000000032, 0x00000001006d0000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace CODESIGNING, Code 0x2
kernel messages:
VM Regions Near 0x1006d0000:
--> mapped file 1006d0000-100920000 [ 2368K] r-x/r-x SM=COW Object_id=513e2ddb
mapped file 100920000-100cd0000 [ 3776K] rw-/rw- SM=COW Object_id=513e2ddb
Backtrace not available
Unknown thread crashed with ARM Thread State (64-bit):
x0: 0x00000001006d0000 x1: 0x000000016f72f928 x2: 0x000000016f72f8d8 x3: 0x0000000101239f03
x4: 0x000000000000003d x5: 0x000000000000003d x6: 0x000000016f72f680 x7: 0x0000000000000630
x8: 0x000000016f72f908 x9: 0x000000016f72f8e8 x10: 0x000000010125ea78 x11: 0x0000000000000000
x12: 0x0000000000000000 x13: 0x000000000000002d x14: 0x0000000000000000 x15: 0x0000000000000000
x16: 0x000000010120e084 x17: 0x6ae100016f72f8d8 x18: 0x0000000000000000 x19: 0x000000016f72f928
x20: 0x00000001006d0000 x21: 0x000000016f72f8d8 x22: 0x00000001006d0000 x23: 0x000000016f72fa88
x24: 0x000000016f72faf8 x25: 0x000000016f72f9c0 x26: 0x0000000000000000 x27: 0x0000000000000000
x28: 0x000000016f72fa68 fp: 0x000000016f72f8c0 lr: 0x2d2b80010120e04c
sp: 0x000000016f72f840 pc: 0x0000000101210470 cpsr: 0x80000000
far: 0x00000001006d0000 esr: 0x92000007
Binary images description not available
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
VM Region Summary:
Writable regions: Total=9040K written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=9040K(100%)
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
STACK GUARD 56.0M 1
Stack 8176K 1
VM_ALLOCATE 1.0G 2
VM_ALLOCATE (reserved) 672K 2 reserved VM address space (unallocated)
mapped file 7536K 7
=========== ======= =======
TOTAL 1.1G 13
TOTAL, minus reserved VM space 1.1G 13
Model: MacBookPro17,1, BootROM 6723.120.36, proc 8:4:4 processors, 8 GB, SMC
Graphics: kHW_AppleM1Item, Apple M1, spdisplays_builtin
Memory Module: LPDDR4
AirPort: spairport_wireless_card_type_airport_extreme, wl0: Apr 28 2021 19:53:33 version 18.50.40.7.7.8.119 FWID 01-e6894c69
Bluetooth: Version 8.0.5d7, 3 services, 25 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB 3.1 Bus
USB Device: USB 3.1 Bus
Thunderbolt Bus: MacBook Pro, Apple Inc.
Thunderbolt Bus: MacBook Pro, Apple Inc.
My local copy of build-emacs-for-macos is up-to-date with master
That's interesting. Seems that it's complaining that the app (or parts of it) do not have a valid code signature. Which of course, they don't cause you haven't signed the app yourself.
My best guess is that some of the libraries which are embedded into the app bundle causes macOS on ARM to be very strict, and decides to error out. While on x86_64 it's not as strict.
Any chance you have a Apple developer account and some experience with signing macOS apps? Cause if yes I'd be curious to see if signing it will fix the issue. (there's a custom CLI tool to help with signing the app too)
Interesting, I did hear that M1 arm apps are more strict now.
Unfortunately, I don't have an Apple developer account, haven't really worked with signing macOS apps specifically
Not a problem. I'll leave this open for now, and can hopefully come up with some answers at some point soon.
In the meantime, the Emacs.app from within the sources/**/nextstep folder is working for you right?
Yes! It does work and is actually faster than its x86 counterpart. For example, older builds of x86 take about ~4.6 seconds to boot up, while the arm version only takes about ~2 seconds.
I'll use the local bound-to-homebrew-packages app for now
Wait, it's x86 counterpart? Or do you mean the version from the *.tbz archive? My understanding so far is that x86 builds insta-crash on M1 machines and fail to run through Rosetta.
I think I phrased it oddly, I still have older emacs x86_64 builds (before the code signing commits) from June 2nd, which work great! I'm currently using that x86_64 build from June 2nd (master was up-to-date then).
If I build a new x86_64 now let's say, the issue seems to just insta-crash as well, so I'm reserving to my old builds or the bound-homebrew arm build
Are those builds from an Intel-based mac? Cause I was under the impression that you could only build arm64 variants on M1 machines, and x86_64 variants on Intel-based machines.
Actually, M1 can build both! I have two instances of iTerm2, where one is running in native arm mode, the second one is running in Rosetta2's emulation mode.
Basically, I pull up my x86_64 terminal and build emacs there, which is then compiled in x86_64 mode. Building an arm emacs is something that just started working at all. Before, the compilation would crash completely due to unrecognized symbols (I thought some libraries weren't cross-arch, so I always built x86_64 versions)
Oh, that's actually very interesting. And your x86 Emacs build have Application (Intel) as kind if you Get Info on the app? I've had a few friends try x86 builds and they just instantly crashed.
Also, if you haven't seen it already, I've made x86 pre-built nightlies available on https://github.com/jimeh/emacs-builds and would be very curious to hear if they work at all for you :)
Here are two of my emacs versions I have right now! Yes, I always built Intel versions on my M1
I'll try the emacs builds later and will write an update on how it goes here. So from the picture above, you can see I have my x86_64 version build using build-emacs-for-macos on June 2nd
Update: such is life of an M1 ¯\_(ツ)_/¯. I even have two versions of home-brew running, one is running in x86 mode and the second one in arm mode, because some bottles are only available in x86 mode and some bottles are way faster if native. Same goes for terminals and emacs
Thanks for the confirmation. That's awesome to see, and puts my mind at even more ease of the potential prospect for getting a Apple Silicon machine sometime soon :)
Oh, that's actually very interesting. And your x86 Emacs build have
Application (Intel)as kind if you Get Info on the app? I've had a few friends try x86 builds and they just instantly crashed.Also, if you haven't seen it already, I've made x86 pre-built nightlies available on https://github.com/jimeh/emacs-builds and would be very curious to hear if they work at all for you :)
The nightly bottle recipes have an architecture restriction:
~ λ rbrew install --cask emacs-app-nightly
==> Downloading https://github.com/jimeh/emacs-builds/releases/download/Emacs.2021-07-08.4bfdf8
==> Downloading from https://github-releases.githubusercontent.com/365391989/c7441500-e052-11eb
######################################################################## 100.0%
Error: Cask emacs-app-nightly depends on hardware architecture being one of [{:type=>:intel, :bits=>64}], but you are running {:type=>:arm, :bits=>64}.
@thecsw ah yes, indeed. I added that cause I was under the impression intel builds didn't work at all on M1 machines. For a quick test right now you can simply grab the dmg from the latest nightly pre-release here: https://github.com/jimeh/emacs-builds/releases
@jimeh Got the build from July 11th!
Works like a charm!
Was the build completed on a single core? When emacs is trying to compile the native lisp files, it only uses a single core, and because it tries to compile it to x86, it's taking a while to do so even through Rosetta
Woo, nice :)
And no, it was compiled on GitHub Actions' macOS runners which have three cores, and using all three cores. The exact make command used was:
make -j 3 BYTE_COMPILE_EXTRA_FLAGS=--eval '(setq comp-speed 2)' NATIVE_FULL_AOT=1
The full build log for the 2021-07-11 build is available here: https://github.com/jimeh/emacs-builds/runs/3042217416?check_suite_focus=true
@jimeh my friend, it works like a charm!!
Both the GUI and daemon work fantastic. I must say, I've been using emacs server for years, until I got the M1 and I just couldn't figure out in time how to use daemon, so I moved to GUI. Now, both of them work!
