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

[Drew Adams]

Replying to these long messages is getting long...

My report was essentially an FYI.  It shows what
happens on my laptop.  The ELC I provide should let
you repro the problem.

> > > Just to confirm:
> > > 1. does the machine where this occurs have MSYS including libgccjib
> > > and gcc, and if so
> >
> > No idea, but most likely not.  It's not a software
> > development laptop.  No gcc or other C compiler,
> > for sure.
> 
> Than it is indeed a mystery why we are getting an error related to not
> finding libgccjit.  As best we expect (and to the extent of my still
> fairly limited understanding, it is true that) ... [this sentence will
> be right back, after after these further inline quotations]

Not sure what you're saying, there, but I guess you're
indicating that the machine should not need any C
compiler, or MSYS or libgccjit.  If so, great.  And if
so, then yes, it seems like a mystery.

I can't guarantee I don't have any of those dev tools on
my laptop, but the error msg seems to say, at least,
that it can't find libgccjit.  So it seems that it _is_
required to have that.

> > > 2. is bin folder of that MSYS installation on your path?
> >
> > No MSYS, most likely.
> >
> > > 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.

BTW, you've been writing "libgccjib", but the error
msg speaks of a missing "libgccjit".  Is what you're
writing just a typo, or is the error msg wrong, or is
something else going on?

> ... we do not need to have MSYS, much less libgccjit, to use an Emacs
> binary that has been compiled with support for native compilation.
> Natively compiling additional ELN won't be possible and shouldn't be
> attempted in that case.  That said, when MSYS (or GCC or libgccjit)
> isn't installed (or isn't on the path when we start Emacs, even so the
> (currently very few) ELN files provided with the release should work.
> In my testing this has held true.

I see.  So it should work not to have libgccjit.  So
that particular error should _not_ have been raised.

> > I also don't understand, if Emacs native compiling
> > tries to use existing *.elc files, why it doesn't
> > fall back to using the *.el, if trying to compile
> > natively from the *.elc raises an error.
> 
> I'm fairly sure Emacs is not (at least, should not be) trying to
> execute native compilation.

OK.  I thought the backtrace was saying that it was
trying to native-compile:

 error("Cannot find libgccjit library")
 comp-ensure-native-compiler()
 comp--native-compile((lambda (arg0 &optional arg1 arg2 arg3)...)
 ^^^^^^^^^^^^^^^^^^^^

> > IOW, in the case of this small Elisp file, why would
> > Emacs depend on using a *.elc if present, and simply
> > give up if trying to use it raises an error.  The
> > source of truth is (should be) *.el, not *.elc.
> 
> That sounds like a feature request to me:
> 
> [wishlist] When an error occurs loading the ELC, attempt loading
> from the EL file (given the EL file is present locally).

OK by me.  But as you've made clear now, in my case no
attempt to native-compile should occur.  My problem is
that it seems to be occurring, hence my suggestion that
Emacs try the EL, if it can't do what it wants with the ELC.

> I was assuming you tried to use your elc intententioonaly as a way to
> test the new binaries,

No.  All I did was invoke runemacs.  That loads my init
file, which loads various libraries.  The fact that an
ELC is present for a library favors loading it, instead
of the EL.  That's normal.

> and that you have good  reason to expect that to work.

Why shouldn't it work to load existing ELC files?
That's what Emacs has always been able to do.

> I want to be able to (e.g.) run Emacs 27 sometimes, but I don'tt want errors
> from packages that may have been compiled with Emacs 28 or snapshot builds.

Of course.  And it could turn out that some ELC can't
be loaded in Emacs 28, for example, because it tries
to invoke some function that no longer exists.

That I would understand.  That's not what's happening
here, IIUC.  There's no Lisp error raised for the ELC
code.

Likewise, it could turn out that some ELC can't be
loaded because it's incompatible.  In that case, most
likely a Lisp error would be raised.  At the very
least, I'd expect an error saying that the ELC isn't
compatible with Emacs 28.

Instead, it looked (to me) like the native compiler
kicked in and tried to natively compile the library
using that ELC.  AND it looked (to me) like the error
raised was the absence of libgccjit.

You've said that it did _not_ try to natively compile
the library, so what I thought was wrong.  I have no
idea what the problem is, in that case.

> Can you confirm it is expected that byte-complied files are promised
> to be forward compatible?  This is outside my experience.

No, they are not.  That's not the problem - see above.

If loading Emacs told me that there's some Lisp
problem then I'd know what I might need to change.
And I might need to no longer byte-compile that
library (so it continues to work with Emacs 28, as
well as older versions).

Similarly, if Emacs said that the ELC file was
incompatible with Emacs 28.

I wouldn't have reported that as a problem.  What
I thought I was reporting was a complaint by Emacs
that I don't have libgccjit, and I thought that
complaint came from trying to natively compile from
an ELC.

> AFAIK, from the Emacs developer perspective, the "most compiled" form
> of an elisp package becomes it's "machine readable feature" file

I know nothing about that, and it means nothing
to me.  (I don't even know what "most compiled"
means.)
 
> and, as such, that should be the only version which is technically
> needed for Emacs to support what functionality it provides.

I can't speak to that.  Again, my concern isn't that
that ELC be acceptable to Emacs 28.  My concern is
that Emacs seems to be complaining that I'm missing
libgccjit.

> So, in the case
> of an ELC being present, removing the EL file completely should be
> harmless:  it is essentially documentation and ought to safe to remove
> when the user/distro doesn't want it.

That may be.  I think it's irrelevant here.  And for
authors of a library, at least, the EL is the single
source of truth.  (I'm the author of strings.el.)

> In point of fact, I can't
> remember reading about whether it's safe for end-users (or distros) to
> remove an ELC when using/shipping an ELN for the feature.

I have no idea about that.  I know nothing about ELN.

> > If it's no longer possible to use a Windows binary
> > unless you have such development tools installed,
> > then Emacs 28 and later will be useless, for me at
> > least.
> 
> Fortunately, this is not the case.  Neither by intention nor (so far
> in my own testing) in fact.

Good to hear.  But that error message still says the
contrary, to me.  It doesn't seem to be Emacs saying
that something particular in that ELC file produces
a particular Lisp error.  It seems to be the Emacs
native compiler saying that the ELC file can't be
natively compiled because libgccjit is missing.

> As far as I've seen when testing without MSYS, Emacs is
> able to load and utilize ELN files even when MSYS isn't available.
> (Although it can't create/update any ELN files, notwithstanding your
> experience, I haven't found any place where it errors out because,
> e.g. libgccjit is missing.)

Well, you seen one such place now.  You were able
to repro the problem using the ELC I sent, right?

> To summarize my own understanding/expecations:
> 
> - Emacs works fine when MSYS isn't around

What about libgccjit?  That's what the error seems
to complain about, not MSYS.

> - Nattive Comp is only available when MSYS is around
> - ELN files are created only when Native Comp is available
> - ELN files are preferred when they are present
> - ELC files are used when no ELN exists
> - EL files are used only when no ELC exists
> - We are warned loading an ELC newer than it's EL
> - Likewise when loading an ELN newer than it's ELC
> 
> I hope and trust that you will LMK if anything I've said suggests what
> you are trying may not be supported (and likewise for anything
> seeminly untrue or very unexpected in what I've said).

I don't think I have anything helpful to add.  I'm
hoping that you can figure out this regression
based on the ELC file I provided.

Perhaps, as you say, libgccjit is _not_ really
needed, and in that case perhaps the wrong error
is raised and that can be corrected to point to an
actual Lisp problem (e.g. because the ELC isn't
supported by Emacs 28).