Error message when starting: "1"

[dertuxmalwieder]

I am absolutely willing to finally give native compilation a run. For this very reason, I fetched the latest "known working build" (2021-07-12 by the time of me writing this) and installed it on my Big Sur (Intel) MacBook. I renamed my init.el first so nothing could interfere with it yet. (I used other builds until today, but they don't have native compilation yet.)

Anyway, I can't start Emacs.app.

Why?

[jimeh]

Errr, that's interesting. Sorry for the hassle, but I can't say I've ever seen anything like that error. So we're gonna need to do a little bit of debugging I'm afraid.

Can you try launching Emacs from a terminal with -Q to ensure it's not loading any configuration? It should hopefully yield a bit more of a verbose error message to help point at what's going wrong.

Something like this:

/path/to/Emacs.app/Contents/MacOS/Emacs -Q

If that works, try without -Q.

And you can also try adding -nw flags to launch it as a terminal application instead of a GUI app, that might give some more/different errors too if it fails.

[dertuxmalwieder]

Ah:

Error using execdir /Applications/Emacs.app/Contents/MacOS/:
emacs: dlopen(/Applications/Emacs.app/Contents/MacOS/../Frameworks/native-lisp/28_0_50-006389d9/preloaded/window-0d1b8b93-63c191c3.eln, 1): Library not loaded: /usr/local/lib/gcc/11/libgcc_s.1.dylib
  Referenced from: /Applications/Emacs.app/Contents/Frameworks/native-lisp/28_0_50-006389d9/preloaded/window-0d1b8b93-63c191c3.eln
  Reason: image not found

Makes sense.

However, this feature is probably not quite true then:

Self-contained Emacs.app application bundle, with no external dependencies.

I would really prefer to not have to install Homebrew - it clutters my file system (and last time I tried, it couldn't even complete). Is there a way to circumvent this?

[jimeh]

Ah, seems an old bug has come back to haunt me. But it's a also a bit more complicated. Indeed the "no external dependencies" part is not quite true for the nightly builds right now due to a bug :(

The *.eln files bundled within the app should all have been re-linked against an embedded libgcc_s.1.dylib, that used to work, but based on your error, it looks like it no longer does :(

However, the second issue, is that all dynamically built *.eln files (built when the user is running Emacs) also link against the absolute path for the Homebrew installed copy of that GCC shared library, and I have not yet figured out a way to make Emacs dynamically pick up the embedded copy instead of the absolute path. I'm tracking this issue on https://github.com/jimeh/build-emacs-for-macos/issues/53 but I'll create an issue here on the builds repo too. That's why GCC is listed as a requirement in the readme for the nightly builds right now. I'll update the readme to point out it's a bug, and link to the relevant issue.

Now, interestingly, before I started signing and notarizing Emacs.app, it was capable of picking up libgcc_s.1.dylib from within the Emacs.app bundle, but I have not figured out a way to make that work yet when the app is signed. I assume it's because the signing process does modify the dylib file itself.

As for work arounds, until I figure out the shared lib linking issue with *.eln files, I think there's three options, but two of them involve installing Homebrew :(...

• Try the last nightly build before I started signing the app, it worked in my testing in a macOS VM, but you will need to right click > Open on the .app bundle to force macOS to give you the option to launch the app, as it's not signed or notarized. https://github.com/jimeh/emacs-builds/releases/tag/Emacs.2021-06-20.434c059.master
• Install Homebrew, and then install the gcc formula, nothing else should be needed. This also has the benefit of you being able to actually install and update emacs via the brew cask.
• Build Emacs from source yourself with my buildscript, which will also require Homebrew: https://github.com/jimeh/build-emacs-for-macos

If the last unsigned nightly build works for you, I can change how the build process works slightly, so it keeps a tar archive as a build asset from before the signing process is started, allowing you (and anyone) to easily grab a unsigned copy of each nightly build.

[dertuxmalwieder]

I am currently trying the second option. Again, the Homebrew installation does not complete successfully (something with Fish completions which is irrelevant to me anyway), but it seems to be able to build GCC. At least my MacBook makes quite some noise now.

As I don't plan to keep Homebrew on my system longer than needed, I'll still wait for #53 to be fixed. However, the build from 2021-06-20 does work and it does feel snappy. :-)

[jimeh]

@dertuxmalwieder I've finally managed to figure out what the issue was that prevented the bundled GCC libraries from being used, so starting with build 2021-11-27 tomorrow, native-comp should work without Homebrew or GCC installed, and be truly self-contained.

If you want to try a build early, there's a test build that I used to verify things worked. Simply download the "dmg" artifact from here: https://github.com/jimeh/emacs-builds/actions/runs/1509465027

You should get a zip file caled dmg.zip, within which you'll have Emacs.2021-11-26.9721dcf.master.macOS-10-15.x86_64.test.rpath2.dmg.

Details about the root cause of the issue, and the fix/fixes, are on this PR: https://github.com/jimeh/build-emacs-for-macos/pull/62

[dertuxmalwieder]

Awesome, thank you for the fix and the good documentation. :)

I hope I’ll manage to test it over the weekend.

[dertuxmalwieder]

The latest build from your link cannot load my init.el file:

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun
libgccjit.so: error: error invoking gcc driver
Debugger entered--Lisp error: (native-ice "failed to compile" "/Users/tux0r/.emacs.d/eln-cache/29_0_50-e6091003/s..." "error invoking gcc driver")
  comp--compile-ctxt-to-file("/Users/tux0r/.emacs.d/eln-cache/29_0_50-e6091003/s...")
  comp-compile-ctxt-to-file("/Users/tux0r/.emacs.d/eln-cache/29_0_50-e6091003/s...")
  comp-final1()
  load-with-code-conversion("/private/var/folders/tq/7ds0xd3d13lgzvj4qkdgknhh00..." "/private/var/folders/tq/7ds0xd3d13lgzvj4qkdgknhh00..." nil t)
  command-line-1(("-l" "/var/folders/tq/7ds0xd3d13lgzvj4qkdgknhh0000gn/T/e..."))
  command-line()
  normal-top-level()

Seems like I still need a library?

[jimeh]

Ah, right, you do need the Xcode Command Line Tools for compilation to work, I'm not sure there's a way around that sadly. You should be able to install them with:

sudo xcode-select --install

I haven't tested it with this build, but a while back in a fresh macOS VM I was prompted to install the Xcode Command Line Tools the first time native-comp was triggered.

[dertuxmalwieder]

It worked on the "old" builds though. But I upgraded to macOS Monterey in between, that could have been the problem... Said command fixes it. :-)

So I'm running the latest build now without a visible problem. Thank you!

[jimeh]

Awesome, the upgrade makes sense. Looking again at your error while not half-asleep, it looks like your system thinks it has the Xcode Command Line Tools, but fails when it tries to actually use them.

I actually had the same issue when I upgraded to Monterey, and had to the run the same command to force-reinstall them :)

[jimeh]

@dertuxmalwieder also thanks for your help and patience with this issue :)