Aquamacs on Apple Silicon

[alexanderkoller]

Hi,

with the impending release of the first Macs with Apple Silicon, are there are any plans to release a version of Aquamacs that can run natively on the M1?

Or will this be really hard given outstanding issues such as #182 and #186?

Best,
Alexander.

[davidswelt]

Hi Alexander, I was wondering the same thing, actually. I have ordered one of the new laptops, so maybe I can help make or test a build, but development and management of this is up to Win of course!

[treese]

I certainly hope we can have it working on Apple Silicon soon. There are a few issues I know about:

1. Right now, I can't build Aquamacs on Catalina. There's a bug in the bootstrap process. It seems to be fixed in the main Emacs 28 code (and maybe in 27), but as far as I can tell the necessary change came with a lot of gnulib changes, and it wasn't easy to figure out if there's an isolated change to back port. I'm going to take another look at that later this week.

2. It might be if Xcode 12 is available on Mojave, then it could build there, even for both architectures. As far as I can tell, it's not.

3. I haven't yet worked through the newer application certification process for smooth validation of distributed binaries.

If we can figure out how to get it built for the new systems, I'd be happy to make a release very quickly for them.

Other thoughts welcome!

[treese]

I found a patch for building Emacs 26 on Catalina, and it seems to work fine. It's now in the aquamacs3 branch, and the nightly build will probably switch to being done on Catalina very soon. #182 is closed now.

The word on the net seems to have people running Emacs under Rosetta on Apple Silicon, but it's not clear that anyone has it compiling there yet. There are reportedly issues with various dependencies, notably gnutls. So we'll see how it goes. First one to get a new Mac can give it a go!

The notarization work of #186 just looks like something to slog through, and I'm planning that for 3.6 in any case.

I'm marking this as a "feature request" now, without a milestone, because I'm not yet sure how we'll get there. But we will.

[alexanderkoller]

Thank you so much for your efforts, and I look forward to seeing a native Aquamacs in the not-too-distant future!

[Grigoletti2001]

Stupid question, but how hard would it be to get it to run using clang as opposed to GCC? That seems to be easier way to best way to get things working long term as both Microsoft and Apple are adopting Clang as well as many linux users.

[alexanderkoller]

Oh, just for the record, the nightlies work on Apple Silicon under Rosetta. At least the nightly of December 12 that I downloaded seems to work without a problem. That said, of course a native version would be amazing.

[treese]

@Grigoletti2001 Not a stupid question at all! But it turns out we've been using clang for a long time. The Emacs build process calls for gcc, but Xcode is delivered with a "gcc" program that is just a wrapper for clang, so that's what actually gets called.

From what I understand, there are some issues with M1 compilation of some of the pieces we need for a full Aquamacs build.

[treese]

@alexanderkoller Glad to hear it works under Rosetta! I hope we can get it going native in 2021.

[Grigoletti2001]

@Grigoletti2001 Not a stupid question at all! But it turns out we've been using clang for a long time. The Emacs build process calls for gcc, but Xcode is delivered with a "gcc" program that is just a wrapper for clang, so that's what actually gets called.

From what I understand, there are some issues with M1 compilation of some of the pieces we need for a full Aquamacs build.

You are too kind :) I'm relatively new to the Computer science field. I did ok in my Programming languages course and will have to retake Systems II (c level code is hard!, but the first time around I learned a lot).

I'm not sure if this is how Aquamacs works, but I do know Emacs does have a Universal Binary, thus it runs native on x86 and ARM 64 (I just picked up a m1 Mac on New Years day and I'm running it now and it's great). Would it make sense to use rewrite emacs (the existing version), from a fork, and simply add the unique features of Aquamacs?

[davidswelt]

Sorry, none of that is “simple”. Win is working hard to port the latest Emacs version. Aquamacs works great on my M1 MacBook, even if it is Intel code.

…

On Jan 4, 2021, 00:39 -0500, Joseph Grigoletti ***@***.***>, wrote: > @Grigoletti2001 Not a stupid question at all! But it turns out we've been using clang for a long time. The Emacs build process calls for gcc, but Xcode is delivered with a "gcc" program that is just a wrapper for clang, so that's what actually gets called. > From what I understand, there are some issues with M1 compilation of some of the pieces we need for a full Aquamacs build. You are too kind :) I'm relatively new to the Computer science field. I did ok in my Programming languages course and will have to retake Systems II (c level code is hard!, but the first time around I learned a lot). I'm not sure if this is how Aquamacs works, but I do know Emacs does have a Universal Binary, thus it runs native on x86 and ARM 64 (I just picked up a m1 Mac on New Years day and I'm running it now and it's great). Would it make sense to use rewrite emacs (the existing version), from a fork, and simply add the unique features of Aquamacs? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[treese]

Here's an outline of the things I know need to be done for having Aquamacs native on M1/Apple Silicon. I don't have an M1 system to work with yet. I'm happy to work with anyone who wants to tackle any of it.

For Aquamacs on M1 as a separate distribution:

1. Look into what's been done for other Emacs distributions on M1.
2. See if Aquamacs will build and run for individual use on an M1 system, without including gnutls. (This is somewhat limited, because you can't install packages this way, although you might be able to copy over the files from an x86 setup).
3. See if gnutls and its package dependencies now works on M1. Better yet, have it building via Homebrew. There may be some other dependencies we end up needing, but that's the big one.

For Aquamacs on M1 as a universal binary (which would be nice, but not essential to start):

1. Figure out how to tweak the Aquamacs build for this
2. Figure out how to build gnutls, etc., as libraries in universal form (which I assume is theoretically possible, but I haven't looked into that)

There are probably some things I haven't though of yet.

[bestlem]

I am a longish time Aquamacs user but switched to current emacs - actually the mituhara port https://bitbucket.org/mituharu/emacs-mac/commits/all as Aquamacs development seemed to have stopped and I hit a problem with swiper - and I had time.

I have taken some aquamacs setup to that - not much so not enough to build on. (and I don't use all Aquamacs changes)

But might it be easier to start with a emacs 27/8 build (which does build on Apple Silicon as I am using it) and add the aquamacs changes to that?

Is there an easy way to find the diffs between aquamacs and a GNU emacs 25.3.50.1?

As for gnutls - macports builds it on Apple Silicon - I have a mac mini and got it. If you are set up to get universal builkds on macports then if there is an arm build then you will get a universal one - if the arm does not work e.g. rust builds then you only get an intel build. Macports has the framewoirk to do universal builds - they still maintain ports for ppc i386 x86_64 and now arm64 over OSX going back to Tiger in the best case.

The dirty way of building universal is do two builds and then use lipo to stick them together. However I am not certain if that is the best way - as you will want the intel build to support earlier version of macos and so will differ (I have used lipo since the NeXT but it is done at the compile stage so each .o file is universal.)

[bestlem]

I tried a build of Aquamacs on MI.

First all the tex is a problem - it is not clear exactly what is needed - so I commented that out. Not really a problem as that can be copied from an Intel build

Then it fails on
Dumping under the name emacs
unexec: my_edata is not in section __data

I though this was fixed for Catalina in #182 and I can see that code change but it is not sufficient. Do we need to change to a portable dump?

I am happy with coding in elisp and C and Objective C but just do not know anything of the internals of emacs.

[treese]

Thanks for giving it a try. I was afraid something like that might be a problem.

After the upcoming 3.6 release, which is all short-term bug fixes, I'm planning to update the main Aquamacs code to Emacs 28, which may be the best path forward on this (as you suggested on the developers mailing list).

[treese]

@bestlem Hi, Mark. I got my communications sources mixed up. Sorry about that.

I am a longish time Aquamacs user but switched to current emacs - actually the mituhara port https://bitbucket.org/mituharu/emacs-mac/commits/all as Aquamacs development seemed to have stopped and I hit a problem with swiper - and I had time.

I can understand the frustration with where Aquamacs is. At the moment, development is underway, with a lot to do. I wasn't aware of any problems with swiper, but one never knows, and I don't use it myself.

But might it be easier to start with a emacs 27/8 build (which does build on Apple Silicon as I am using it) and add the aquamacs changes to that?

As noted in the previous reply, my plan is to migrate Aquamacs to Emacs 28 for "Aquamacs 4.0", starting as soon as the upcoming maintenance release 3.6 is done. It will probably take a while.

Is there an easy way to find the diffs between aquamacs and a GNU emacs 25.3.50.1?

The main merge with Emacs 25 code was around commit 2a7b43d in October 2018.

As for gnutls - macports builds it on Apple Silicon - I have a mac mini and got it. If you are set up to get universal builkds on macports then if there is an arm build then you will get a universal one - if the arm does not work e.g. rust builds then you only get an intel build. Macports has the framewoirk to do universal builds - they still maintain ports for ppc i386 x86_64 and now arm64 over OSX going back to Tiger in the best case.

Glad to hear it's working on Macports. For complicated reasons, the current process for building Aquamacs releases is tied to Homebrew, but a quick look suggests that they've made a lot of progress since I last looked, so it may not be an issue.

The dirty way of building universal is do two builds and then use lipo to stick them together. However I am not certain if that is the best way - as you will want the intel build to support earlier version of macos and so will differ (I have used lipo since the NeXT but it is done at the compile stage so each .o file is universal.)

Good to know! I'm not an expert on that corner of Mac development, so this is helpful.

[davidswelt]

What if everyone helped with the port to the latest Emacs? That way you'd get improvements to dumping directly. I have an M1 Mac and Aquamacs 3.5 runs fast on it.

…

On Mon, Feb 1, 2021 at 12:50 AM Mark Bestley ***@***.***> wrote: I tried a build - after removing the makinfo bits (textlive on macports is not enough but that is not a real issue as the documentation can be built elsewere) It failed on the dumping etc. The build needs to be converted to pdump - I hoped that was the fix for #182 <#182> but that seems not. re the merge etc - the point I ws trying to make is - can we say what are the aquamacs chnages to normal emacs 25 are - can we then start with a emacs 27 build (which does work on Apple Silicon) and apply those chnages to it or have we got to continue on the current branch and merge emacs 27 in? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#199 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGMLIJIJNQFWPPWNPH6JLS4XUDJANCNFSM4TU3Q26A> .

[bestlem]

I think that the direction needs to be set by Win and David as they know the Aquamacs code - do we start witrh current Aquamacs and merge in newer GNU code or start with GNU and add Aquamacs chnages in?

Also how can the port be split?

[treese]

I was prompted by this discussion to start a specific issue on how we go about doing Aquamacs 4.0: #211. It starts with a question about how we would generally approach it, and part of the answer to @bestlem's last question depends on whether we have multiple people doing the work.

We'll keep this issue open for the Apple Silicon version. Thanks!