Cannot find /usr/local/lib/gcc/11/libgcc_s.1.dylib

[AllenDang]

This issue occurred since the *.dmg version.

Start Emacs.app, error messages are:

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"

I found libgcc_s.1.dylib at /Applications/Emacs.app/Contents/MacOS/lib/libgcc_s.1.dylib, seems the reference is wrong.

[jimeh]

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.

[AllenDang]

@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"

[jimeh]

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.

[AllenDang]

@jimeh I've done brew uninstall gcc and brew install gcc issue remains...

[jimeh]

@AllenDang interesting, do you have /usr/local/lib/gcc/11/libgcc_s.1.dylib on disk?

[AllenDang]

@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

[jimeh]

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

[AllenDang]

@jimeh Aha! Case solved after brew link --overwrite gcc.

[Kloenk]

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.

Output running doom

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

[jimeh]

@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"

[Kloenk]

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.)

[jimeh]

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.

[Kloenk]

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.

[Kloenk]

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)

[jimeh]

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.

[Kloenk]

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.