railwaycat/homebrew-emacsmacport

Does not work with Mojave yet (tested with beta 3)

Closed this issue ยท 24 comments

GUI window opens, but input is more or less unresponsive. Terminal interface works better. I can exit the GUI with C-x C-c just fine, and it beeps when I press C-g etc, so it feels like the whole "output"/GUI stuff simply does not work. Pressing some keys in blind, I sometimes get a response (it opens a buffer), but typically only sometimes and with massive latency.

I tried rebuilding as well, but it failed. It seems the author of this emacs port is active here https://bitbucket.org/mituharu/emacs-mac . I also tried building that, but failed. Last commit from author is only two days old though, and I see from the commits that 10.14 support is being worked on. In the meantime for people who NEED their editor back, the easiest way currently seems to be:

brew cask install emacs

So another update from me, seems the latest release from the original author (his work branch) is working (haven't tested it much though yet). There's a few issues though:

  1. Make sure you've got the Xcode10 beta installed, and the command line tools.
  2. Make sure you've got /usr/include to compile (most) software. It is NOT installed by step 1 above. You need to manually run /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg as root
  3. Check out the latest source from the original developer https://bitbucket.org/mituharu/emacs-mac/branches/
  4. Switch to his work branch, i.e. git checkout work
  5. Compile according to the instructions

Of course this is all on your own risk, I'm assuming the original author will let us know when it is appropriate for another official release.

glyph commented

From this line in the formula:

  head "https://bitbucket.org/mituharu/emacs-mac.git", branch: "work"

I am guessing that brew install emacs-mac --HEAD will do the trick as well?

Regarding emacs-mac --HEAD you are correct, although right now there seems to be an issue (since a few days ago):

$ brew install emacs-mac --HEAD
Updating Homebrew...
==> Auto-updated Homebrew!
Updated Homebrew from b119591c to 664bd9ac.
No changes to formulae.

==> Installing emacs-mac from railwaycat/emacsmacport
==> Cloning https://bitbucket.org/mituharu/emacs-mac.git
Updating /Users/marius/Library/Caches/Homebrew/emacs-mac--git
==> Checking out branch work
Already on 'work'
Your branch is up to date with 'origin/work'.
HEAD is now at fa9204daa8 use mac_menu_set_in_use when showing print dialogs
==> ./autogen.sh
==> ./configure --enable-locallisppath=/usr/local/share/emacs/site-lisp --infodir=/usr/local/Cellar/emacs-mac/HEAD-fa9204d/share/info/emacs
==> make
Last 15 lines from /Users/marius/Library/Logs/Homebrew/emacs-mac/03.make:
  CC       fontset.o
  CC       fringe.o
  CC       image.o
  CC       macappkit.o
  CC       macfont.o
  CC       terminfo.o
  CC       lastfile.o
  CCLD     temacs
Undefined symbols for architecture x86_64:
  "_IODisplayMatchDictionaries", referenced from:
      ___mac_display_copy_info_dictionary_for_cgdisplay_block_invoke in macappkit.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [temacs] Error 1
make: *** [src] Error 2

But usually, --HEAD does the trick just fine.

Interestingly, right now I can build from source manually just fine, but brew install emacs-mac --HEAD fails with the error I showed above.

My curiosity made me look into the build differences a bit. When building under brew install, the ./configure script detects /usr/bin/clang as the compiler, while building straight from source detects /usr/bin/gcc. Both of these are the same size, and the output from -v and timestamps also indicates they were installed at the same time. They are not the same file though as the md5 signatures differ.

BUT, building straight from source with gcc also add this line:

Configured with: --prefix=/Applications/Xcode-beta.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1

which is added to the gcc invocation line if I understand it correctly.

This may very well be due to something unique to my setup, considering I've been running Mojave since beta 3 and Xcode 10 betas, but at least it probably explains why the build fails when building under Homebrew (I'm guessing the prefixes are needed for the linker to find it's stuff).

So I've narrowed it down do this: Under the brew build environment (brew install -i), both gcc -v and clang -v returns the following:

Apple LLVM version 10.0.0 (clang-1000.10.38)
Target: x86_64-apple-darwin18.0.0
Thread model: posix
InstalledDir: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Outside of brew, clang -v outputs the same, but gcc -v outputs:

Configured with: --prefix=/Applications/Xcode-beta.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.10.38)
Target: x86_64-apple-darwin18.0.0
Thread model: posix
InstalledDir: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Since it builds ok from source using gcc with the Configured with ... line as the only difference I'm inclined to conclude that this is the major difference. I haven't been able to figure out exactly why gcc/clang behaves differently under the brew build environment yet.

So narrowed it further down. When building inside the brew environment, the first entry in that path is:

/usr/local/Homebrew/Library/Homebrew/shims/mac/super

That has symlinks and stuff various ways of calling the compiler it seems. With that in the path, the build FAILS as described. Inside that directory, gcc links to ../../super/cc, which is a cc executable dated a few days before the latest versions of gcc and clang inside my /usr/bin directory. Doing a cc -v on that directory outputs the identical output I have shown earlier here (the "Configured with ..." stuff is missing).

For the hell of it, I replaced the cc inside the .... /mac/super directory with a symlink to /usr/bin/gcc, and attempted to build using the regular brew install emacs-mac --HEAD. And it worked perfectly.

So at least from this package's point of view, effectively using /usr/bin/gcc instead of /usr/bin/clang (or /usr/bin/cc which points to clang) works much better (well, it's the only thing that is working at my end currently).

Am I the only one struggling with this?

I am able to build with brew install emacs-mac --HEAD on mojave, but I see the same behavior with the display not updating in the GUI. Were you able to get it working?

I have just built using brew install emacs-mac --HEAD on macOS Mojave with Xcode 10 (no cc muddling necessary) and see that it does work; the non-responsive GUI is now perfectly responsive. If it's any help, this was commit e0575e7.

@aaronstockdill Same setup as you, but still no joy.

I had to force uninstall emacs-mac first. It now works!

brew uninstall --force emacs-mac && brew install emacs-mac --HEAD

Also can confirm.

  1. Install Mojave
  2. Upgrade to Xcode 10 using App Store
  3. Uninstall and re-install emacs-mac worked.
ezchi commented

@shen-tian do you add "--HEAD" when install emacs-mac?

I'm using command line tools with/without "--HEAD" and almost everything is working fine now. Yet the font looks strange. The normal weight in GUI emacs looks the same as the light weight in iterm2.app, which is my usual choice. It seems like there is some anti-aliasing issue.

@shen-tian do you add "--HEAD" when install emacs-mac?

@ezchi No I did not.

@LukeXuan Any luck with font issue?

@noorul No. I'm using normal weight rather than light weight as temporary solution for now.

The Mojave version is known for its conflict with subpixel rendering. I'm not sure how it can be solved.

This works for me (i.e. it doesn't crash on open anymore with Mojave): brew uninstall --force emacs-mac && brew install emacs-mac --HEAD.

However, it now crashes every time I click on the toolbar (it seems stable with keyboard only so far).

Had the same issue of the toolbar crashing in Mojave.
Commit 9e3e44d fixes this issue for me.

I tried commit https://bitbucket.org/mituharu/emacs-mac/commits/9e3e44dd1935f0783bcc97c089e31a073840e5c3 but it has the same issue. I click on 'tools' and it crashes.

Upgrading to Mojave, upgrading Xcode, then re-installing the latest release from this project (for Mojave) worked for me. But I noticed it seemed very slow. I pulled up Activity Monitor and it uses 15-50% CPU, then drifts down to zero within a few seconds when you shift the focus to another app.

UPDATE: I'm no longer seeing slow performance or CPU elevation since I uninstalled the pre-built binary and re-installed using homebrew. That made a big difference.

Just to keep this ticket update with the latest info I have. After the new Xcode release and removing the old Xcode-beta, making sure to install the latest command line tools as well, everything seems to build and run just fine by default. I'm not seeing any slowdowns either that other people have mentioned.

After upgrading to Mohave, the normal emacs-mac available through brew led to immediate crashing when the menu bar was clicked. I am currently at:

This is YAMAMOTO Mitsuharu's "Mac port" addition to
GNU Emacs 26. This provides a native GUI support for Mac OS X
10.6 - 10.14. After installing, see README-mac and NEWS-mac
in /usr/local/Cellar/emacs-mac/emacs-26.1-z-mac-7.3 for the port details.

This version limits the menu bar crash, but I still often find Emacs unresponsive after waking from sleep, possibly due to window resizing as a result of changes in external monitor size (between work and home).