Closed AllenDang closed 3 years ago
Interesting. The eln file in question is in your /Users/allendang/.emacs.d/.local/cache/eln/28.0.50-b01b8d59
directory, not one that’s bundled into the app. So the issue seems to be that your cached .eln
files link against a homebrew install of gcc, which no longer exists.
The eln files bundled into the app are relinked against a embedded copy of the shared lib as of about two weeks ago with v0.4.16 of the build script. But I haven’t checked what user made eln files are linked to.
If you trash the /Users/allendang/.emacs.d/.local/cache/eln/28.0.50-b01b8d59
folder and let emacs redo the native comp, it should link against the lib within Emacs.app and work. Or alternatively simply install gcc: brew install gcc
However, this does highlight that user-cached eln files could cause problems, so I’ll do a bit of digging and put some information together in the readme.
This also highlights the need for some basic automated tests to be part of the build process, which I’ve been meaning to write up an issue for since a few weeks back.
@jimeh Remove /Users/allendang/.emacs.d/.local doesn't help, error msg remains as below.
❯ doom sync
> Installing straight...
> Cloning use-package...
Native elisp load failed: "/Users/allendang/.emacs.d/.local/cache/eln/28.0.50-b01b8d59/subr--trampoline-6d657373616765_message_0.eln", "dlopen(/Users/allendang/.emacs.d/.local/cache/eln/28.0.50-b01b8d59/subr--trampoline-6d657373616765_message_0.eln, 1): Library not loaded: /usr/local/lib/gcc/11/libgcc_s.1.dylib
Referenced from: /Users/allendang/.emacs.d/.local/cache/eln/28.0.50-b01b8d59/subr--trampoline-6d657373616765_message_0.eln
Reason: image not found"
Okay, now that is a lot more interesting. I'm gonna need to do some digging to figure out if I can get native-comp produced files to link elsewhere.
For now only workaround I can think of is brew install gcc
so the missing dylib file is available.
@jimeh I've done brew uninstall gcc
and brew install gcc
issue remains...
@AllenDang interesting, do you have /usr/local/lib/gcc/11/libgcc_s.1.dylib
on disk?
@jimeh /usr/local/lib/gcc/11/
is symbol linked to /usr/local/Cellar/libgccjit/11.1.0/lib/gcc/11
, and here is the content.
lrwxr-xr-x 1 allendang admin 14 4 27 18:20 libgccjit.so -> libgccjit.so.0
lrwxr-xr-x 1 allendang admin 18 4 27 18:20 libgccjit.so.0 -> libgccjit.so.0.0.1
-rw-r--r-- 1 allendang admin 35776728 6 23 14:19 libgccjit.so.0.0.1
gcc version is
gcc (Homebrew GCC 11.1.0_1) 11.1.0
That doesn't seem right. It shouldn't symlink to the libgccjit package, it should be symlinking to gcc.
This is what my machine looks like with gcc
and libgccjit
homebrew formula installed:
$ ls -lah /usr/local/lib/gcc/11/libgcc_s.1.dylib
lrwxr-xr-x 1 jimeh staff 56B Jun 20 18:44 /usr/local/lib/gcc/11/libgcc_s.1.dylib -> ../../../Cellar/gcc/11.1.0_1/lib/gcc/11/libgcc_s.1.dylib
~$ ls -lah /usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11/
total 214296
drwxr-xr-x 54 jimeh staff 1.7K Jun 20 18:44 .
drwxr-xr-x 3 jimeh staff 96B Apr 27 11:20 ..
drwxr-xr-x 3 jimeh staff 96B Apr 27 11:20 gcc
-r--r--r-- 1 jimeh staff 1.0M Jun 20 18:44 libasan.6.dylib
lrwxr-xr-x 1 jimeh staff 15B Apr 27 11:20 libasan.dylib -> libasan.6.dylib
-r--r--r-- 1 jimeh staff 5.1K Apr 27 11:20 libasan_preinit.o
-r--r--r-- 1 jimeh staff 73K Jun 20 18:44 libatomic.1.dylib
-r--r--r-- 1 jimeh staff 229K Apr 27 11:20 libatomic.a
lrwxr-xr-x 1 jimeh staff 17B Apr 27 11:20 libatomic.dylib -> libatomic.1.dylib
-rw-r--r-- 1 jimeh staff 2.0M Apr 27 11:20 libcc1.0.so
lrwxr-xr-x 1 jimeh staff 11B Apr 27 11:20 libcc1.so -> libcc1.0.so
-r--r--r-- 1 jimeh staff 21K Apr 27 11:20 libgcc_ext.10.4.dylib
-r--r--r-- 1 jimeh staff 20K Apr 27 11:20 libgcc_ext.10.5.dylib
-r--r--r-- 1 jimeh staff 165K Jun 20 18:44 libgcc_s.1.dylib
lrwxr-xr-x 1 jimeh staff 16B Apr 27 11:20 libgcc_s_ppc64.1.dylib -> libgcc_s.1.dylib
lrwxr-xr-x 1 jimeh staff 16B Apr 27 11:20 libgcc_s_x86_64.1.dylib -> libgcc_s.1.dylib
-r--r--r-- 1 jimeh staff 1.8M Jun 20 18:44 libgdruntime.2.dylib
-r--r--r-- 1 jimeh staff 5.0M Apr 27 11:20 libgdruntime.a
lrwxr-xr-x 1 jimeh staff 20B Apr 27 11:20 libgdruntime.dylib -> libgdruntime.2.dylib
-r--r--r-- 1 jimeh staff 3.1M Jun 20 18:44 libgfortran.5.dylib
-r--r--r-- 1 jimeh staff 13M Apr 27 11:20 libgfortran.a
lrwxr-xr-x 1 jimeh staff 19B Apr 27 11:20 libgfortran.dylib -> libgfortran.5.dylib
-r--r--r-- 1 jimeh staff 198B Apr 27 11:20 libgfortran.spec
-r--r--r-- 1 jimeh staff 384K Jun 20 18:44 libgomp.1.dylib
-r--r--r-- 1 jimeh staff 1.9M Apr 27 11:20 libgomp.a
lrwxr-xr-x 1 jimeh staff 15B Apr 27 11:20 libgomp.dylib -> libgomp.1.dylib
-r--r--r-- 1 jimeh staff 169B Apr 27 11:20 libgomp.spec
-r--r--r-- 1 jimeh staff 9.2M Jun 20 18:44 libgphobos.2.dylib
-r--r--r-- 1 jimeh staff 31M Apr 27 11:20 libgphobos.a
lrwxr-xr-x 1 jimeh staff 18B Apr 27 11:20 libgphobos.dylib -> libgphobos.2.dylib
-r--r--r-- 1 jimeh staff 305B Apr 27 11:20 libgphobos.spec
-r--r--r-- 1 jimeh staff 246K Jun 20 18:44 libitm.1.dylib
-r--r--r-- 1 jimeh staff 1.6M Apr 27 11:20 libitm.a
lrwxr-xr-x 1 jimeh staff 14B Apr 27 11:20 libitm.dylib -> libitm.1.dylib
-r--r--r-- 1 jimeh staff 162B Apr 27 11:20 libitm.spec
-r--r--r-- 1 jimeh staff 162K Jun 20 18:44 libobjc-gnu.4.dylib
-r--r--r-- 1 jimeh staff 514K Apr 27 11:20 libobjc-gnu.a
lrwxr-xr-x 1 jimeh staff 19B Apr 27 11:20 libobjc-gnu.dylib -> libobjc-gnu.4.dylib
-rw-r--r-- 1 jimeh staff 335K Jun 20 18:44 libquadmath.0.dylib
-r--r--r-- 1 jimeh staff 1.2M Apr 27 11:20 libquadmath.a
lrwxr-xr-x 1 jimeh staff 19B Apr 27 11:20 libquadmath.dylib -> libquadmath.0.dylib
-r--r--r-- 1 jimeh staff 327B Apr 27 11:20 libsanitizer.spec
-rw-r--r-- 1 jimeh staff 54K Jun 20 18:44 libssp.0.dylib
-r--r--r-- 1 jimeh staff 59K Apr 27 11:20 libssp.a
lrwxr-xr-x 1 jimeh staff 14B Apr 27 11:20 libssp.dylib -> libssp.0.dylib
-r--r--r-- 1 jimeh staff 2.1K Apr 27 11:20 libssp_nonshared.a
-rw-r--r-- 1 jimeh staff 3.4M Jun 20 18:44 libstdc++.6.dylib
-r--r--r-- 1 jimeh staff 23M Apr 27 11:20 libstdc++.a
-r--r--r-- 1 jimeh staff 2.4K Jun 20 18:44 libstdc++.a-gdb.py
lrwxr-xr-x 1 jimeh staff 17B Apr 27 11:20 libstdc++.dylib -> libstdc++.6.dylib
-r--r--r-- 1 jimeh staff 5.0M Apr 27 11:20 libstdc++fs.a
-r--r--r-- 1 jimeh staff 1.0M Apr 27 11:20 libsupc++.a
-r--r--r-- 1 jimeh staff 429K Jun 20 18:44 libubsan.1.dylib
lrwxr-xr-x 1 jimeh staff 16B Apr 27 11:20 libubsan.dylib -> libubsan.1.dylib
@jimeh Aha! Case solved after brew link --overwrite gcc
.
From what I can tell, this is still an issue. Tried using this on m1 with Ventura. It only works If I put a gcc 11 for x86 in my path, I't seems to be unable to use the system gcc (which is AFAIK just a clang wrapper?). Complains about a version 13.00.00.
x There was an unexpected runtime error
Message: Native compiler error
Details: ((lambda (arg47 &rest arg48) (let ... ...)) "Compiling /Users/kloenk/.emacs.d/.local/cache/eln/29_0_50-9d1a6069/subr--trampoline-6d657373616765_message_0.eln...\nx86_64-apple-darwin19-gcc-11: warning: could not understand version 13.00.00\nld: library not found for -ldylib1.o\nlibgccjit.so: error: error invoking gcc driver\nInternal native compiler error: \"failed to compile\", \"/Users/kloenk/.emacs.d/.local/cache/eln/29_0_50-9d1a6069/subr--trampoline-6d657373616765_message_0.eln\", \"error invoking gcc driver\"\n\nError: native-ice (\"failed to compile\" \"/Users/kloenk/.emacs.d/.local/cache/eln/29_0_50-9d1a6069/subr--trampoline-6d657373616765_message_0.eln\" \"error invoking gcc driver\")\n debug-early-backtrace()\n debug-early(error (native-ice \"failed to compile\" \"/Users/kloenk/.emacs.d/.local/cache/eln/29_0_50-9d1a6069/subr--trampoline-6d657373616765_message_0.eln\" \"error invoking gcc driver\"))\n comp--compile-ctxt-to-file(\"/Users/kloenk/.emacs.d/.local/cache/eln/29_0_50-9d1a6069/subr--trampoline-6d657373616765_message_0.eln\")\n comp-compile-ctxt-to-file(\"/Users/kloenk/.emacs.d/.local/cache/eln/29_0_50-9d1a6069/subr--trampoline-6d657373616765_message_0.eln\")\n comp-final1()\n load-with-code-conversion(\"/private/var/folders/3z/8gkxf5k97ng3tswrp5dh548w0000gn/T/emacs-int-comp-subr--trampoline-6d657373616765_message_0-RHn6na.el\" \"/private/var/folders/3z/8gkxf5k97ng3tswrp5dh548w0000gn/T/emacs-int-comp-subr--trampoline-6d657373616765_message_0-RHn6na.el\" nil t)\n command-line-1((\"-l\" \"/var/folders/3z/8gkxf5k97ng3tswrp5dh548w0000gn/T/emacs-int-comp-subr--trampoline-6d657373616765_message_0-RHn6na.el\"))\n command-line()\n normal-top-level()\n")
Backtrace:
(signal native-compiler-error ((lambda (arg47 &rest arg48) (let ((f #'me...
(comp--native-compile (lambda (arg47 &rest arg48) (let ((f #'message)) (...
(comp-trampoline-compile message)
(comp-subr-trampoline-install message)
(fset message #[128 "\302\301\303\300\"\"\207" [(#s(doom-cli-context (...
(progn (fset #'message vnew) (progn (if (or init-file-debug noninteracti...
(unwind-protect (progn (fset #'message vnew) (progn (if (or init-file-de...
(let* ((vnew (doom-partial #'doom-cli--redirect-output-a context)) (old ...
(let ((standard-output (doom-rpartial #'doom-cli--output context))) (let...
(let ((debug-on-error t)) (let ((standard-output (doom-rpartial #'doom-c...
(let ((debugger (doom-rpartial #'doom-cli-debugger context))) (let ((deb...
(let ((show-benchmark-fn (doom-partial #'doom-cli--output-benchmark-h co...
! Wrote extended backtrace to ~/.emacs.d/.local/logs/cli.doom.220720145053.34691.error
Not yet fluently enough with emacs/elisp, to check if this only occurs with doom
Version tested is Emacs.2022-07-18.7a93716.master.macOS-10-15.x86_64
and Emacs.2022-07-12.113a6a0.master.macOS-10-15.x86_64
@Kloenk That's interesting, this should no longer be an issue as the builds have been usingu versions of gcc and libgccjit which are embedded into the .app bundle itself since late November last year.
That said, I'm don't have any first-hand experience of using these builds on M1-based machines myself yet. And the builds here are Intel-only for now, as GitHub does not yet have M1-based GitHub Actions runners available.
But yeah, if it somehow is trying to use the system gcc, that would definitely not work if it's the clang wrapper, as libgccjit specifically requires actual GCC. But, in theory it should be both libgccjit and GCC bundled into the app, admittedly running it all via Rosetta2 on an M1 machine, but still.
What's the value of the LIBRARY_PATH
env var in your running emacs session? You can eval (getenv "LIBRARY_PATH")
in a scratch buffer or something to get the value.
It should include a couple of paths within your Emacs.app, for example, mine is:
"/Applications/Emacs.app/Contents/Frameworks/gcc/11:/Applications/Emacs.app/Contents/Frameworks/gcc/11/gcc/x86_64-apple-darwin20/11:/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"
My value is /Applications/Emacs.app/Contents/Frameworks/gcc/11:/Applications/Emacs.app/Contents/Frameworks/gcc/11/gcc/x86_64-apple-darwin19/11
so missing the CommandLineTools
.
I actually can't find a binary called gcc inside the app folder. only the dylibs, a gcc.h header and a eln file containing gcc in the filename. Under which names is a binary supposed to exists?
(Doom uses an env file, to restore a known environment. LIBRARY_PATH
is part of that file, containing this value.)
The Xcode Command Line Tools are required. But on a Intel-based macs you'll be prompted by macOS to install them first time Emacs tries to perform any native compilation. Possibly that doesn't happen on M1-based machines as these builds would be running through Rosetta2.
So if you don't already have the Xcode Command Line Tools installed, try installing it.
Alternatively, you could try using my build script to compile Emacs yourself for M1. Though from what I've understood, you'll need to also sign the app which requires a paid Apple Developer Program membership.
As for the gcc paths within the Emacs.app bundle, there won't be any gcc
executable, it's just the various shared libraries that make up gcc and libgccjit. Native compilation is triggered via C library calls rather than executing the gcc
binary.
I have the Xcode tools installed. I know that clang via a command line works. gcc is AFAIK a 3 layered wrapper for the same clang.
Using the build script is some work for me. As I don't have (and want) homebrew. Already have nix for all my needs. (Nix is where I got a gcc binary from that did get it to work)
Hmm, I wonder if maybe Rosetta apps don't see the M1-based Xcode Command Line Tools? I'm afraid Apple Silicon is still very much uncharted territory and guess work for me.
As for the build script, in theory it shouldn't need Homebrew. Only real dependency of the script itself is Ruby (2.3 or later), and Xcode Command Line tools (the otool
and install_name_tool
binaries specifically). The Brewfile
is basically just a easy way to get various things available to Emacs' own build system. So in theory if you could install the same things with nix, it should work fine. Though you'd still need a paid for Apple Developer account so you can sign the app.
A native M1 build should perform better as there'd be no x86 translation happening via Rosetta, but I don't know if performance is even remotely a concern in your case.
Will look into it after my exams :). There is an eMacs inside nixpkgs, but it does not compile natively. But I think it uses different patches.
A paid developer account I do have. And even without it, it should be possible I then just have to rebuild every week.
This issue occurred since the *.dmg version.
Start Emacs.app, error messages are:
I found libgcc_s.1.dylib at /Applications/Emacs.app/Contents/MacOS/lib/libgcc_s.1.dylib, seems the reference is wrong.