alpha.gnu.org has shiny new Emacs 28.0.91 Windows binaries

The title probably says it all. Get them here: [https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-28/?C=M;O=D](https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-28/?C=M;O=D) Read more, here: [https://lists.gnu.org/archive/html/emacs-devel/2022-02/msg00153.html](https://lists.gnu.org/archive/html/emacs-devel/2022-02/msg00153.html) PS, I only show up on Reddit to snarf karma :P I will try to remember to drift back this way and look at comments but .. TIA if you can share/discuss breakage via M-x report-emacs-bug

Using `emacs-28.0.91.zip`, I get `Cannot find libgccjit library`. It seems [decision was made not to included it with Emacs](https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01494.html). Where does one find libgccjit library for Windows 10?

It seems it is [a known problem](https://lists.gnu.org/archive/html/emacs-devel/2022-02/msg00164.html). >> As I strongly suspect you know: We aren't providing libgccjib+gcc with >> the Emacs 28 distributions, at least we haven't decided to do that so >> far. > No, I don't know. And I don't know what libgccjib+gcc > is, or why I would want or need it on my laptop.

`gcc` and `libgccjit` are needed for native complication, which enables emacs to run faster. On Windows, you can get both through [msys2](https://www.msys2.org/). You can install by running: `pacman -S mingw-w64-x86_64-gcc mingw-w64-x86_64-libgccjit `

It worked flawlessly. I just copied the resulting file from `C:\msys64\mingw64\bin\libgccjit-0.dll` to my `emacs\bin\` and now `(native-comp-available-p)` returns a glowing `t`. I hope somebody will just put the lib somewhere available for all. Thank you so much.

Nice! You could add `C:\msys64\mingw64\bin` to your path and get updates (by running pacman) and also be able to use more Linux tools from emacs. For instance you could install aspell and dictionaries for your flycheck spellcheck.

What you suggest is what I've been guiding people to do (put the msys bin folder into the windows PATH), but... I should also document that u/lispstudent's approach works also. FTR, I have been thinking of packaging up versions that do include GCC+libgccjit and also a version that includes NATIVE\_FULL\_AOT. That last is a flag to `make` which causes all of the lisp sources shipped with Emacs to be natively compiled. In theory, this works even when libgccjit isn't around so, for example, people in locked-down environments where we aren't allowed compilers can have the performance boost u/curioushom described. I've been using NATIVE\_FULL\_AOT when self-building (both emacs-28 and from trunk) for some time and I've been quite pleased, so it would be great to get more folks trying that out: I'm leaning toward lobbying for it to be the default for windows binary distributions.

I suggest to everyone who is interested to run pretest versions or master to build their own Emacs. It really isn't very difficult and is probably just as fast as browsing for and downloading someone else's binaries. The additional benefit is that you will have configured environment with all libraries and requirements to run Emacs in (msys2 or whatever build system you opt for) as well as an Emacs configured to your liking and not someone elses.

FWIW, I completely agree - building Emacs from source (even on Windows) is fun and easy to do. That said, I'm pleased GNU distributes binary versions of Emacs. Not all Emacs users are programmers (believe it or not) and in many cases may not have access to compilation tools in the places where we'd like to use Emacs. As a for instance, at my workplace we have a "BYO-Editor" policy allowing us to download (e.g.) Emacs despite the locked-down nature of our workstations, generally. Unfortunately, installing (for example) MSYS requires each person to file paperwork that must receive approval from multiple leaders (direct manager, security team rep, etc). The first time I installed Emacs at work I had to work a bunch of issues related to automated scans that are run on our PCs however, with that done, the rules generated from my working with our security tools and desktop field support teams have been promoted, so everyone can simply download and use Emacs now at my workplace.

I suspect you could be running into an issue that was reported earlier today. Eli (an emacs maintainer) has a small patch that might solve this. I've packaged that up if you are able to try it out I'd be grateful for the feedback and happy to pass it back along to Eli and the [Emacs developer mailing list](https://lists.gnu.org/archive/html/emacs-devel/) (or please feel free to report your findings there yourself, if so inclined). [https://git.sr.ht/\~mplscorwin/emacs-w64/tree/master/item/patched](https://git.sr.ht/~mplscorwin/emacs-w64/tree/master/item/patched) Or skip browsing the repo with this [download link](https://git.sr.ht/~mplscorwin/emacs-w64/blob/master/patched/emacs-28.0.91.zip). And a link to [view the patch](https://git.sr.ht/~mplscorwin/emacs-w64/tree/master/item/patched/comp_no-local-gccjit.patch) (to/for the emacs-28 branch).

**Everyone**? Are you saying only devs should be using a pre-release of Emacs? Or every user should should be able to build Emacs if they want to find bug in it before the release?

This works for me, I downloaded and uncompressed the zip file and run `runemacs.exe` with no errors. Also, `(native-comp-available-p)` retunrs `t`. Thank you!

Thanks!

I just want to say thank you for taking this on. Thank you thank you thank you.

Just to be clear: the patched version may (seems to) solve an issue where the binaries don't work properly for people who do not have MSYS+libgccjit. I'd still be grateful for reports from folk who haven't installed `libgccjit` and then messed with the Windows `PATH`, copied DLLs, etc. post-install/unpack.

Very much my pleasure; thanks for the comment!

I have a fairly large emacs config. Everything worked fine using MSYS2 libgccjit, except the block below that I use as a use-package boostrap gives me `Symbol's function definition is void: package-installed-p` Any idea? `(unless (package-installed-p 'use-package)` `(package-refresh-contents)` `(package-install 'use-package))` On the upside: After emacs has autocompiled every .el Emacs feels super snappy on windows.

> I don't know what libgccjib+gcc is, or why I would want or need it on my laptop. You *don't* need them on your laptop. That's why (pre-release bugs notwithstanding) it's fine that it's not included.

I managed to get native compilation working \*without\* msys2 (for those that can not or do not want to maintain an msys2 installation, like myself). We need to copy several executables from a working (up-to-date) msys2 installation though, as just copying `libgccjit-0.dll` as sometimes implied is not enough: `bin/libgccjit-0.dll` `lib/gcc/crtbegin.o` `lib/gcc/crtend.o` `lib/gcc/dllcrt2.o` `lib/gcc/libadvapi32.a` `lib/gcc/libgcc.a` `lib/gcc/libgcc_s.a` `lib/gcc/libkernel32.a` `lib/gcc/libmingw32.a` `lib/gcc/libmingwex.a` `lib/gcc/libmoldname.a` `lib/gcc/libmsvcrt.a` `lib/gcc/libpthread.a` `lib/gcc/libshell32.a` `lib/gcc/libuser32.a` `libexec/emacs/28.0.91/x86_64-w64-mingw32/ld.exe` `libexec/emacs/28.0.91/x86_64-w64-mingw32/as.exe` Note that these are the target locations where the files need to go. You'll need to locate these yourself in an msys2 installation which has package `mingw-w64-x86_64-libgccjit` installed. The above will enable synchronous native compilation. Asynchronous compilation did not work for me after the above steps. It looks like it spawns sub processes with a wrong `default-directory` or something like that. I don't know how to debug the sub processes, I need some help with that. But I found a workaround; for asynchronous native compilation I needed to add the following to `early-init.el` : `(setenv "PATH" (concat exec-directory ";" (getenv "PATH")))`

No native emoji support?

It looks to me like `package-installed-p` does not have an autoload. I'll open a bug report to suggest adding one. Meanwhile... Does it help to add `(require 'package)` before the config snippet you showed? Thanks for sharing your result!

I believe that will come with Emacs 29 🕘

Neat! Thanks for digging into this! For async, I would first try using [ProcessExplorer](https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer) to catch the additional dependencies being loaded during async. Perhaps, first triggering a synchronous native compilation, then doing an async job and comparing. (We can save the list of DLLs shown in the DLL pane pressing C-c with that process selected in the process list pane) Also, this has me wondering if it would make sense to distribute (e.g.) `emacs-28-more-deps.zip`. This could provide all that is needed for native compilation to function on a "non-development" (e.g. No-MSYS) Windows environment. I guess this could be done such that we just need to unpack the additional dependencies zip file atop an Emacs 28 install, and go. I think your research gives what is needed to "one-off" Phil Lord's work in `admin/nt/build-dep-zips.sh`. That is convenient to help meet GPL requirements because it also creates an archive from sources of MSYS packages used, as required to distribute binaries of GPLed work. WDYT?

And see shiny new bug report, here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53885

Yes, it does. On emacs <28 I didn't need that. I configure package using use-package.

Umm, could it be that the "Insert and evaluate" block of the bug report already contained the workaround, so if someone reproduces it he will not get the error presented under "Actual result"?

~~Ohh, so it's a regression! Yay, that makes it pretty likely it will get fixed before Emacs 28, I think.~~ \[EDIT\] Can you explain your approach under Emacs <28? I'm not sure I can demonstrate this is actually a regression, which I'd like to do to help "lobby" for fixing it before 28.1 is released. Thanks for pointing out/confirming the error with my reproducer, also.

Nice, they're also the files that I included in my emacs build script to be able to get native-comp without msys2 installed. https://github.com/kiennq/emacs-build/blob/9d02548a946c79c5e8129d6b38c48d1b4f4c08e7/emacs-build.sh#L349 I kind of remember the problem with asynchronous compilation is not working with my build script before, but it has gone away after I add the `bin` folder under Emacs to `PATH`. It was complaining about missing `as.exe` at that time though.

New reply because the thread was getting TL;DR.. Adding an autoload for `package-installed-p` was considered as a feature request.Until (presumably) Emacs 29 we'll need to use something like: (require 'package) (unless (package-installed-p 'use-package) (package-install 'use-package)) (I'm pretty sure the call to `pacakge-refresh-contents` is taken care of when we call `package-install`, so I've removed it. That said, I was arguing about this very thing on the bug tracker; it's possible I'm wrong and unlikely to be harmful as I read the code if you want to keep it.) \[\[Edited because Reddit ate my markdown.\]\]

Not sure what you mean. In emacs <28 the codeblock in my original post is just read and throws no errors. Now in emacs 28 I get the error shown in the original post. When I add `(require 'package)` in emacs 28 before the codeblock I don't get an error and emacs loads.

Can someone check the variable "shell-file-name"? For some reason it shows "c:/users/corwi/..." I don't have a user corwi. It should display "c:/users/(myusername)/..."

Can you say what version, exactly? Here's what I get from Emacs 27 with -Q: [https://bru.st/i/emacs\_XaVNMHHGpj.png](https://bru.st/i/emacs_XaVNMHHGpj.png)

Hmm.. that sounds like a problem. Does M-x shell work? Thanks for letting me know.

It does. But I still don't have a user "corwi". Used latest built from 2022-02-13. `"C:/_Software/Portable/Emacs/libexec/emacs/28.0.91/x86_64-w64-mingw32/cmdproxy.exe"` `Original value was` `"C:/Users/corwi/emacs-build/build/emacs-28.0.91/nt/cmdproxy.exe"`

OK. Glad it works, anyway. I'll have a look at where this is being set during the build. We might be able to clean this up in the installer, if that's not done already. Do you install or just unpack the zip version?

zip unpack. I just stumbled on this by accident. Typically it's set to bash to work with MSYS2+fakecygpty.

I used the installer. My variable appears to be set correctly, but it shows Original value was "C:/Users/corwi/emacs-build/build/emacs-28.0.91/nt/cmdproxy.exe"