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

[Drew Adams <drew.adams@oracle.com>]

> > >> > I cannot reproduce this.  How exactly did you load strings.elc?
> > >>
> > >> M-x load-file
> > >>
> > >> with (load-file "d:/tmp/Corwin/strings.elc") it isn't working either on
> > >> my machine!?
> > >
> > > Because you loaded a .elc file, explicitly.  Try this instead:
> > >
> > >   M-x load-library RET d:/tmp/Corwin/strings RET
> >
> > Indeed!
> 
> Awesome, thanks for this confirmation.

I just use (require 'strings), and both the EL
and the ELC are in my `load-path'.  (And the ELC
is newer than the EL.)

But anyway, `load-library' and `require', prefer
ELC over the EL:

 If the library name is ‘FOO’, it tries looking for
 files named ‘FOO.elc’, ‘FOO.el’, and ‘FOO’.  The default behavior is to
 load the first file found.  This command prefers ‘.elc’ files over ‘.el’
 files because compiled files load and run faster.  If it finds that
 ‘LIB.el’ is newer than ‘LIB.elc’, it issues a warning, in case someone
 made changes to the ‘.el’ file and forgot to recompile it, but loads the
 ‘.elc’ file anyway.

The backtrace I sent was from doing `M-x load-file'.
I did that to provide a simple recipe from `runemacs -Q'.

But I first ran into this from just invoking Emacs with
my init file.  The backtrace is equivalent, IMO - same
thing, once there's an attempt to load the ELC.  But in
case it helps, here is the backtrace I get with my init
file - `require' is used, not `load-file':

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 -0xb142bd07f69549d>))
  require(strings)
  byte-code("\306\307!\210\10\310W\203\36\0\311\11B\21\312\11B\21\313\11B\21\314\11B\21\315\11B\21\10\316V\2031\0\317\320\321\322\n\323\13\324\f\325&\11\210\10..." [emacs-major-version current-load-list :type :group :version next-error-fringe-indicator require strings 22 compilation-highlight-overlay fringe-indicator-alist next-error-function next-error-last-buffer next-error-recenter 21 custom-declare-variable next-error-highlight 0.5 "*Highlighting of the current locus in selected sou..." (choice (number :tag "Highlight locus for specified time") (const :tag "Highlight locus until move" until-move) (const :tag "Highlight locus until move or next command" t) (const :tag "Do not highlight locus" nil) (const :tag "Indicate locus using fringe arrow" fringe-arrow)) next-error "22.1" next-error-highlight-no-select 0.5 "*Highlighting of locations in `next-error-no-selec..." (choice (number :tag "Highlight locus for specified time") (const :tag "Highlight locus until move" until-move) (const :tag "Highlight locus until move or next command" t) (const :tag "Do not highlight locus" nil) (const :tag "Indicate locus using fringe arrow" fringe-arrow)) #f(compiled-function (&optional arg reset) (interactive "P") #<bytecode 0x150fa3674cc6dae1>) fboundp hl-line-mode next-error-buffer-hl-line #f(compiled-function () #<bytecode 0x127964596bd0f36>) boundp filled-rectangle put variable-documentation "Fringe indicator to use for `next-error' in compil..." next-error-fringe-setup #f(compiled-function () #<bytecode -0xaf425fb13ac875f>) edit-and-eval-command #f(compiled-function (prompt command) #<bytecode -0x18d46e1fe1ec7bcf>)] 10)
  require(simple+ nil t)
  byte-code("\301\302!\210\303\302!\210\10\304V\203\24\0\303\305\306\307#\210\303\310\306\307#\210\303\311\306\307#\207" [emacs-major-version provide start require 21 bindings+ nil t misc-fns simple+] 4)
  require(start)
  load-with-code-conversion("<my init file>" "<my init file>"  t t)
  load("~/.emacs" noerror nomessage)
  startup--load-user-init-file(#f(compiled-function () #<bytecode 0xf88ed2872b5c88c>) #f(compiled-function () #<bytecode -0x1f3c686ddc0da035>) t)
  command-line()
  normal-top-level()

The Emacs 28 binary tries to load strings.elc, and while
doing so runs into a redefinition there of `read-buffer'.
It then tries to natively compile from that ELC (no?).

And the load fails because the compilation fails:
(featurep 'strings) = nil after the error's raised.

If I'm right about this then isn't there a bug in the
Emacs 28 binary?  If not, why not?

Or if it's right that it chokes on the ELC code for
the defun of `read-buffer', isn't it at least bad
that the error message doesn't say anything about
that, but instead says that the problem is that it
can't find library libgccjit?

> I think we now have a good
> sense of where things stand with this report. I'll summarize things
> (especially for Drew's benefit) in a new message, back up-thread.
> First I'm planning to try building emacs-28 with the patch Eli
> suggested, in case I might be able to provide feedback in advance of
> when Andreas can look.
> 
> > [Nitpicking:] Would you consider it an omission that load-library is
> > triggering a compilation but (load-file ".elc") not?  (No, probably not
> > because load-file would need to consider files which are not directly
> > submitted.)
> 
> IMO, no.  It's a feature:  when we specify an extension we get exactly
> what we ask for, when we specify without any extension we get the
> default behavior of favoring the most compiled version available,
> creating the ELN if we can when we have an ELC but no ELN.

Isn't that what's happening?  It tries to load the
ELC.  Not because the extension was specified (it
wasn't, with `require'), but because the ELC exists
and it's more recent than the EL.

IOW, how does this have anything to do with what
code you use to load the ELC?  It looks to me like
the problem occurs no matter how you do that.