Re: [External] : emacs-28 windows binaries available from alpha

[Corwin Brust]

Hi Drew.  Thanks again for this report.  Fairly sure you've found a
bug but it's too soon to say how that will shake out in terms of a
patch for emacs-28 or a change to how we are packaging Emacs binaries
for Windows.

On Fri, Feb 4, 2022 at 4:12 PM Drew Adams <drew.adams@oracle.com> wrote:
>
> I meant to include the backtrace:
>
> Debugger entered--Lisp error: (error "Cannot find libgccjit library")
>                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   error("Cannot find libgccjit library")
>   comp-ensure-native-compiler()
>   comp--native-compile((lambda (arg0 &optional arg1 arg2 arg3) (let ((f 
> #'read-buffer)) (funcall f arg0 arg1 arg2 arg3))) nil 
> "d:/usr/drew/.emacs.d/eln-cache/28.0.91-bfc49136/su...")
>   comp-trampoline-compile(read-buffer)
>   comp-subr-trampoline-install(read-buffer)
>   defalias(read-buffer #f(compiled-function (prompt &optional default 
> require-match predicate) #<bytecode 0x1283e7579f6aadb2>))
>   load-file("~/drews-lisp-20/strings.elc")
>   funcall-interactively(load-file "~/drews-lisp-20/strings.elc")
>   command-execute(load-file record)
>   execute-extended-command(nil "load-file" "load-f")
>   funcall-interactively(execute-extended-command nil "load-file" "load-f")
>   command-execute(execute-extended-command)

I think I see you responding downstream to some slightly tangential
conversation, so I wanted to reassure you:

AFAICT, you've found a problem where Emacs is incorrectly attempting
to invoke native compilation.

Toward confirming/resoving that: Eli has a taken a first pass at
creating a patch for that and has also reached out to Andreas for
additional insight.

Meanwhile, I'm working on testing Eli's patch by building an Emacs
package with it applied and the installing that package on the
"no-MSYS" testing machine I've been using.

I'll report back again once I get that far.