emacs-28 windows binaries available from alpha

emacs-28 windows binaries available from alpha

[Corwin Brust]

Binary distributions from the emacs-28 branch, along with source
archives as of the time of build and for the msys package dependencies
are now available from the GNU alpha FTP site, here:

https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-28/?C=M;O=D

Thanks for any help you can provide testing these. Please use
`report-emacs-bug', as usual, to let us know about problems you
experience.

Dieter (in CC) and I would be grateful to be copied directly when you
suspect the problem you are reporting is related to the packaging (vs
with Emacs 28, more generally).

Here are the files published, along with a brief description of each:

emacs-28.0.91-installer.exe - windows insttaller
emacs-28.0.91.zip - emacs + dependencies (unzip and go)
emacs-28.0.91-no-deps.zip - just emacs, BYO MSYS
emacs-28-deps.zip - dependencies (DLL files) only
emacs-28-deps-mingw-w64-src.zip - sources for dependancies
emacs-28.0.91-src.zip - from the emacs-28 branch

Emacs was built with the following configuration options:
  --with-json
  --without-dbus
  --with-native-compilation
  --without-compress-install
  CFLAGS="-O2"

In order to use the native compilation features included you must have
the MSYS bin folder on your windows path when starting Emacs.  You can
check by evaluating:
  (native-comp-available-p)

Dieter and I would like to thank Phil for tending this process for
many years as well as for providing us excellent tooling and a "warm
handoff".  Thanks also to Eli, Arash, and many others for patiently
nudging us along with emails, bug-reports, and miscellany.

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

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

> Binary distributions from the emacs-28 branch, along with source
> archives as of the time of build and for the msys package dependencies
> are now available from the GNU alpha FTP site, here:
> 
> https://urldefense.com/v3/__https://alpha.gnu.org/gnu/emacs/pretest/windows/
> emacs-
> 28/?C=M;O=D__;!!ACWV5N9M2RV99hQ!aJ2ccv8rhQIAY4zgU1TFcNiuafd_9mWfShQdRC0g6GPX
> PgxqwyEgzjQ79cNHc605$
> 
> Thanks for any help you can provide testing these. Please use
> `report-emacs-bug', as usual, to let us know about problems you
> experience.
> 
> Dieter (in CC) and I would be grateful to be copied directly when you
> suspect the problem you are reporting is related to the packaging (vs
> with Emacs 28, more generally).

Thanks for working on this.

I immediately run into a problem with `runemacs -Q' and then loading a byte-compiled file (strings.elc, attached) compiled with Emacs 20.7.  Dunno whether the problem is Emacs 28 or your packaging.  The source file is here:

https://www.emacswiki.org/emacs/download/strings.el

[-- Attachment #2: strings.elc --]
[-- Type: application/octet-stream, Size: 22756 bytes --]

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

[Drew Adams]

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)

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

[Corwin Brust]

Thanks Drew.

On Fri, Feb 4, 2022 at 4:12 PM Drew Adams <drew.adams@oracle.com> wrote:
>
> I meant to include the backtrace:

I wasn't able to reproduce before you sent this, in so much as the elc
file you had attached loaded for me locally under Emacs 28 without
issue.  Now that I see we're invoking the native compiler I can try
also on the no-MSYS machine where I've been pre-testing the pre-test
packages ;)

Just to confirm:
1. does the machine where this occurs have MSYS including libgccjib
and gcc, and if so
2. is bin folder of that MSYS installation on your path?

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.

>
> 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)

Appreciate the backtrace; I'll reply again when I can attempt testing
in a sans-MSYS environment.

Corwin

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

[Drew Adams]

> Thanks Drew.

You're welcome.  Thanks for producing Windows binaries.
 
> I wasn't able to reproduce before you sent this, in so much as the elc
> file you had attached loaded for me locally under Emacs 28 without
> issue.  Now that I see we're invoking the native compiler I can try
> also on the no-MSYS machine where I've been pre-testing the pre-test
> packages ;)
> 
> 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.

> 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.

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.

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.

I can maybe understand that starting with a *.elc
might be a useful shortcut of some kind, but why
should an error with a *.elc - especially of the
sort that some compiling tool etc. isn't available
- prohibit using an Emacs binary?  Since when
should an Emacs binary depend on such things?

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.

> Appreciate the backtrace; I'll reply again when 
> I can attempt testing in a sans-MSYS environment.

I take that as a hopeful sign that the _intention_
is not to require dev tools such as gcc, msys etc.
to be present on the machine where I use an Emacs
binary.

If that's the intention then great, and I wish you
good luck getting past this hurdle.  Sorry to be
the bearer of the bad news that there are some
Emacs users who don't use software dev tools.

Maybe that will ultimately mean that such users
must forego being able to use natively compiled
code?  If so, that's OK by me - no worse than before.

It's likely that some of what I just wrote betrays
false assumptions or misunderstandings on my part.
I haven't been following the attempt to provide
native compilation.

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

[Corwin Brust]

On Fri, Feb 4, 2022 at 7:29 PM Drew Adams <drew.adams@oracle.com> wrote:
> > 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 libgccjib.  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]

>
> > 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.

... 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 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.


>
> 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).  Note, I didn't do
any research to see if this could already be supported

[[Hope the capitalized file-extentions aren't making this --even--
harder to parse.  I find them easier to read in the midst of human
facing text vs seeing short not-actual-words in the same places.  Let
me know if that's offputting.]]

>
> I can maybe understand that starting with a *.elc
> might be a useful shortcut of some kind, but why
> should an error with a *.elc - especially of the
> sort that some compiling tool etc. isn't available
> - prohibit using an Emacs binary?  Since when
> should an Emacs binary depend on such things?
>

An ELC file, when present, is considered the primary "machine
readable" source for the feature, wnless the corresponding ELN exists
in which case it is.  More on this further down.

I was assuming you tried to use your elc intententioonaly as a way to
test the new binaries, and that you have good  reason to expect that
to work.  For myself (in terms of my own use of Emacs), I keep
separate package repository (ELPA) folders for each installed version
of Emacs.  I thought that was required, at least in as much as 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.   I treat my ELC files as disposable but take care these days
to hang on to my EL files, and go to pains to fetch (and usually
byte-compile) them during startup when they aren't around.  That's a
bit of a different use-case, tho, I believe.

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

AFAIK, from the Emacs developer perspective, the "most compiled" form
of an elisp package becomes it's "machine readable feature" file and,
as such, that should be the only version which is technically needed
for Emacs to support what functionality it provides.  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.  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.

> 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.

>
> > Appreciate the backtrace; I'll reply again when
> > I can attempt testing in a sans-MSYS environment.
>
> I take that as a hopeful sign that the _intention_
> is not to require dev tools such as gcc, msys etc.
> to be present on the machine where I use an Emacs
> binary.

That's quite correct, thus my troubling two of my kiddos for use that
mostly run Minecraft and block-vader, or whatever it is.  On one I
have added MSYS, on the other not.

>
> If that's the intention then great, and I wish you
> good luck getting past this hurdle.  Sorry to be
> the bearer of the bad news that there are some
> Emacs users who don't use software dev tools.
>

That's no news at all.,  At my day-job (generally speaking) I am one of them :)

> Maybe that will ultimately mean that such users
> must forego being able to use natively compiled
> code?  If so, that's OK by me - no worse than before.

I hope not.  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.)

>
> It's likely that some of what I just wrote betrays
> false assumptions or misunderstandings on my part.
> I haven't been following the attempt to provide
> native compilation.

I think (hope) so, yes.  I've done my best to speak directly to these
but let me know where I may have failed.

To summarize my own understanding/expecations:

- Emacs works fine when MSYS isn't around
- 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).

Corwin

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

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Fri, 4 Feb 2022 22:35:39 -0600
> Cc: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> > 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).  Note, I didn't do
> any research to see if this could already be supported

There's no need for such a feature.  Emacs should simply load the .elc
file.  The failure to load does not AFAIU mean that the .elc file is
unusable.  At least the Emacs 28 version built without
native-compilation support has no problems loading it.

IOW, the problem is NOT that this .elc file cannot be used, the
problem is that we try to natively-compile a trampoline for it.  Thus,
there's no need to fall back on loading the .el file instead.

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

[Corwin Brust]

On Sat, Feb 5, 2022 at 1:43 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> IOW, the problem is NOT that this .elc file cannot be used, the
> problem is that we try to natively-compile a trampoline for it.  Thus,
> there's no need to fall back on loading the .el file instead.

I would have expected then when (native-comp-available-p) returns nil
we would not try to create a trampoline.   Does that need fixed?

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

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Sat, 5 Feb 2022 02:48:09 -0600
> Cc: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>,
>  Drew Adams <drew.adams@oracle.com>, Emacs developers <emacs-devel@gnu.org>
> 
> On Sat, Feb 5, 2022 at 1:43 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > IOW, the problem is NOT that this .elc file cannot be used, the
> > problem is that we try to natively-compile a trampoline for it.  Thus,
> > there's no need to fall back on loading the .el file instead.
> 
> I would have expected then when (native-comp-available-p) returns nil
> we would not try to create a trampoline.   Does that need fixed?

I think so, and that's what I asked Andrea up-thread.

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).

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Fri, 4 Feb 2022 22:12:34 +0000
> Cc: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> 
> 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)

Andrea, is this expected on a machine that lacks libgccjit?  Under
what conditions would loading a .elc file trigger native-compilation
of a trampoline?

If this is expected, I'd prefer that we detected the unavailability of
libgccjit earlier, and avoided the attempt to compile a trampoline in
the first place.  Can this be done safely enough to make the change on
the release branch?

Failing that, the error should be converted to a warning message in a
way that doesn't defeat the loading of the .elc file.  Can you suggest
a safe change for that?

Thanks.

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

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Drew Adams <drew.adams@oracle.com>
>> Date: Fri, 4 Feb 2022 22:12:34 +0000
>> Cc: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
>> 
>> 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)
>
> Andrea, is this expected on a machine that lacks libgccjit?  Under
> what conditions would loading a .elc file trigger native-compilation
> of a trampoline?
>
> If this is expected, I'd prefer that we detected the unavailability of
> libgccjit earlier, and avoided the attempt to compile a trampoline in
> the first place.  Can this be done safely enough to make the change on
> the release branch?
>
> Failing that, the error should be converted to a warning message in a
> way that doesn't defeat the loading of the .elc file.  Can you suggest
> a safe change for that?

On a Windows system WITH ligccjit I could load Drew's .elc file without
an error.

Then I added his .el file in the same folder and reloaded the .elc file
(with load-file).  I was expecting that Emacs would create a respective
.eln file in this situation.  But it didn't.

  Loading d:/tmp/Corwin/strings.elc (compiled; note, source file is
  newer)...done

Does this mean that Emacs - by default - is only natively compiling .el
files which are from Emacs' tree and (M)elpa packages?

When (load-file)ing the .el file then Emacs compiled the cl.el library.

  *Asyn-native-compoile-log* Compiling
  d:/tmp/Corwin/2022-02-04/share/emacs/28.0.91/lisp/obsolete/cl.el...

  *Messages* Loading d:/tmp/Corwin/strings.el (source)...
  d:/tmp/Corwin/strings.el: Warning: ‘psetq’ is an obsolete alias (as of
  27.1); use ‘cl-psetq’ instead.

Thanks

        Dieter

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

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Cc: Drew Adams <drew.adams@oracle.com>,  Andrea Corallo <akrl@sdf.org>,
>   corwin@bru.st,  emacs-devel@gnu.org
> Date: Sat, 05 Feb 2022 10:22:26 +0100
> 
> On a Windows system WITH ligccjit I could load Drew's .elc file without
> an error.
> 
> Then I added his .el file in the same folder and reloaded the .elc file
> (with load-file).  I was expecting that Emacs would create a respective
> .eln file in this situation.  But it didn't.

Please repeat this experiment in a fresh Emacs session, started
when the .el file is already available...

>   Loading d:/tmp/Corwin/strings.elc (compiled; note, source file is
>   newer)...done

...and make sure the .elc file is newer, not older, than the .el file.

> Does this mean that Emacs - by default - is only natively compiling .el
> files which are from Emacs' tree and (M)elpa packages?

No.  Emacs should natively compile any .el file when its .elc file is
loaded, provided that (a) the .el file can be found, and (b) the .el
file is older than the .elc file.

> When (load-file)ing the .el file then Emacs compiled the cl.el library.
> 
>   *Asyn-native-compoile-log* Compiling
>   d:/tmp/Corwin/2022-02-04/share/emacs/28.0.91/lisp/obsolete/cl.el...
> 
>   *Messages* Loading d:/tmp/Corwin/strings.el (source)...
>   d:/tmp/Corwin/strings.el: Warning: ‘psetq’ is an obsolete alias (as of
>   27.1); use ‘cl-psetq’ instead.

As expected.  When you load a file with an explicit .el extension,
Emacs will not natively compile that file -- this is a feature.

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

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
>> Cc: Drew Adams <drew.adams@oracle.com>,  Andrea Corallo <akrl@sdf.org>,
>>   corwin@bru.st,  emacs-devel@gnu.org
>> Date: Sat, 05 Feb 2022 10:22:26 +0100
>> 
>> On a Windows system WITH ligccjit I could load Drew's .elc file without
>> an error.
>> 
>> Then I added his .el file in the same folder and reloaded the .elc file
>> (with load-file).  I was expecting that Emacs would create a respective
>> .eln file in this situation.  But it didn't.
>
> Please repeat this experiment in a fresh Emacs session, started
> when the .el file is already available...
>
>>   Loading d:/tmp/Corwin/strings.elc (compiled; note, source file is
>>   newer)...done
>
> ...and make sure the .elc file is newer, not older, than the .el file.

"Touched" and loaded strings.elc.

  -rw-r--r-- 1 uidg1626 Domain Users 34051 Feb  5 10:04 strings.el
  -rw-r--r-- 1 uidg1626 Domain Users 22756 Feb  5 16:54 strings.elc

But it seems that string.el wasn't compiled, I can't see it in
*Asysnc-native-compile-log* neither in eln-cache!?

>> Does this mean that Emacs - by default - is only natively compiling .el
>> files which are from Emacs' tree and (M)elpa packages?
>
> No.  Emacs should natively compile any .el file when its .elc file is
> loaded, provided that (a) the .el file can be found, and (b) the .el
> file is older than the .elc file.

Might it work when the .el files are in PATH or in Emacs' tree?

>> When (load-file)ing the .el file then Emacs compiled the cl.el library.

>>   *Asyn-native-compoile-log* Compiling
>>   d:/tmp/Corwin/2022-02-04/share/emacs/28.0.91/lisp/obsolete/cl.el...
>> 
>>   *Messages* Loading d:/tmp/Corwin/strings.el (source)...
>>   d:/tmp/Corwin/strings.el: Warning: ‘psetq’ is an obsolete alias (as of
>>   27.1); use ‘cl-psetq’ instead.
>
> As expected.  When you load a file with an explicit .el extension,
> Emacs will not natively compile that file -- this is a feature.

Good to know, thank you

--
        Dieter

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

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Cc: corwin@bru.st,  emacs-devel@gnu.org,  drew.adams@oracle.com,  akrl@sdf.org
> Date: Sat, 05 Feb 2022 17:49:31 +0100
> 
> "Touched" and loaded strings.elc.
> 
>   -rw-r--r-- 1 uidg1626 Domain Users 34051 Feb  5 10:04 strings.el
>   -rw-r--r-- 1 uidg1626 Domain Users 22756 Feb  5 16:54 strings.elc
> 
> But it seems that string.el wasn't compiled, I can't see it in
> *Asysnc-native-compile-log* neither in eln-cache!?

I cannot reproduce this.  How exactly did you load strings.elc?

> >> Does this mean that Emacs - by default - is only natively compiling .el
> >> files which are from Emacs' tree and (M)elpa packages?
> >
> > No.  Emacs should natively compile any .el file when its .elc file is
> > loaded, provided that (a) the .el file can be found, and (b) the .el
> > file is older than the .elc file.
> 
> Might it work when the .el files are in PATH or in Emacs' tree?

No, it has nothing to do with PATH or the Emacs tree.

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

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
>> Cc: corwin@bru.st,  emacs-devel@gnu.org,  drew.adams@oracle.com,  akrl@sdf.org
>> Date: Sat, 05 Feb 2022 17:49:31 +0100
>> 
>> "Touched" and loaded strings.elc.
>> 
>>   -rw-r--r-- 1 uidg1626 Domain Users 34051 Feb  5 10:04 strings.el
>>   -rw-r--r-- 1 uidg1626 Domain Users 22756 Feb  5 16:54 strings.elc
>> 
>> But it seems that string.el wasn't compiled, I can't see it in
>> *Asysnc-native-compile-log* neither in eln-cache!?
>
> 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!?

--
     Dieter

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

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Cc: akrl@sdf.org,  corwin@bru.st,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Sat, 05 Feb 2022 20:25:17 +0100
> 
> > 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

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

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
>> Cc: akrl@sdf.org,  corwin@bru.st,  drew.adams@oracle.com,  emacs-devel@gnu.org
>> Date: Sat, 05 Feb 2022 20:25:17 +0100
>> 
>> > 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!

Warning (comp): strings.el:233:10: Warning: `psetq' is an obsolete alias (as of 27.1); use `cl-psetq' instead. Disable showing Disable logging
Warning (comp): strings.el:533:12: Warning: `interactive-p' is an obsolete function (as of 23.2); use `called-interactively-p' instead. Disable showing Disable logging
Warning (comp): strings.el:588:61: Warning: sit-for called with 3 arguments, but accepts only 1-2 Disable showing Disable logging
Warning (comp): strings.el:614:40: Warning: `user-variable-p' is an obsolete function (as of 24.3); use `custom-variable-p' instead. Disable showing Disable logging
Warning (comp): strings.el:762:10: Warning: `interactive-p' is an obsolete function (as of 23.2); use `called-interactively-p' instead. Disable showing Disable logging
Warning (comp): strings.el:495:10: Warning: the function `insert-string' is not known to be defined. Disable showing Disable logging
Warning (comp): strings.el:173:4: Warning: the function `tap-define-aliases-wo-prefix' is not known to be defined. Disable showing Disable logging

[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.)

--
Thanks a lot

       Dieter

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

[Corwin Brust]

On Sat, Feb 5, 2022 at 3:11 PM H. Dieter Wilhelm
<dieter@duenenhof-wilhelm.de> wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> >> Cc: akrl@sdf.org,  corwin@bru.st,  drew.adams@oracle.com,  emacs-devel@gnu.org
> >> Date: Sat, 05 Feb 2022 20:25:17 +0100
> >>
> >> > 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 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.

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

[Drew Adams]

> > >> > 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.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Sun, 6 Feb 2022 00:10:52 +0000
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> If I'm right about this then isn't there a bug in the
> Emacs 28 binary?  If not, why not?

Yes, it's a bug.  I though it should be evident from the questions I
asked Andrea and the patch I posted.

> > > [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.

Happening where?  The above "nitpicking" was not about the problem you
reported, it was about a different situation and about a different
aspect of native compilation.

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

[Drew Adams]

> > If I'm right about this then isn't there a bug in the
> > Emacs 28 binary?  If not, why not?
> 
> Yes, it's a bug.  I though it should be evident from the questions I
> asked Andrea and the patch I posted.

I was replying to Corwin.  I thought he was saying,
then, that there was no bug in what I reported.
 
> > > 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.
> 
> Happening where?

In the problem I reported.  I thought Corwin was
suggesting that it didn't try to load the ELC
and then compile it to ELN.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "corwin@bru.st" <corwin@bru.st>,
>         "dieter@duenenhof-wilhelm.de"
> 	<dieter@duenenhof-wilhelm.de>,
>         "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Sun, 6 Feb 2022 08:51:11 +0000
> 
> > > > 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.
> > 
> > Happening where?
> 
> In the problem I reported.  I thought Corwin was
> suggesting that it didn't try to load the ELC
> and then compile it to ELN.

In the problem you reported here:

  https://lists.gnu.org/archive/html/emacs-devel/2022-02/msg00160.html

indeed Emacs didn't try to compile the .elc file to a .eln.

Like I said: yours was a different situation, not the one about which
Dieter asked his question.

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

[Drew Adams]

> > > > Isn't that what's happening?
> > > > It tries to load the ELC.
> > >
> > > Happening where?
> >
> > In the problem I reported.  I thought Corwin was
> > suggesting that it didn't try to load the ELC
> > and then compile it to ELN.
> 
> In the problem you reported here:...
> indeed Emacs didn't try to compile the .elc file to a .eln.
> 
> Like I said: yours was a different situation, not 
> the one about which Dieter asked his question.

I'm not really interested in a fruitless
back & forth.  A final attempt to clarify
what seems to have confused you about my
"Isn't that what's happening?" question.

I didn't reply to a question from Dieter.
I replied to a post by Corwin, who seemed
to be saying that Emacs didn't try to
load the ELC.  Whether or not that's what
Corwin said or meant isn't at issue.  I'm
explaining why I asked him that question
at that point.

https://lists.gnu.org/archive/html/emacs-devel/2022-02/msg00201.html

https://lists.gnu.org/archive/html/emacs-devel/2022-02/msg00203.html

Yours was apparently a different part of the
overall discussion, with Dieter (?).  You
then jumped in to ask me about my "Isn't that
what's happening?" reply to Corwin, with your
"Happening where?".  I replied to clarify, in
the context of my reply to Corwin.

Perhaps your idea of "what's happening" was
something different from what I referred to.
IOW, perhaps we simply misunderstood what
each other was talking about.

How about we don't waste any more time on
this back & forth.  Fair enough?

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Sun, 6 Feb 2022 17:08:40 +0000
> Cc: "dieter@duenenhof-wilhelm.de" <dieter@duenenhof-wilhelm.de>,
>  "corwin@bru.st" <corwin@bru.st>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> How about we don't waste any more time on
> this back & forth.

It's up to you, really.

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

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Sat, 5 Feb 2022 16:56:58 -0600
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > [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.

Indeed.  Without that, there would be no easy way of asking Emacs to
load a .elc file without natively-compiling it and replacing the .elc
with a .eln.

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

[Eli Zaretskii]

> Date: Sat, 05 Feb 2022 09:25:56 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
> 
> > 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)
> 
> Andrea, is this expected on a machine that lacks libgccjit?  Under
> what conditions would loading a .elc file trigger native-compilation
> of a trampoline?
> 
> If this is expected, I'd prefer that we detected the unavailability of
> libgccjit earlier, and avoided the attempt to compile a trampoline in
> the first place.  Can this be done safely enough to make the change on
> the release branch?

Andrea, how about the following patch (which assumes
comp-enable-subr-trampolines enables and disables only generation of
new trampolines, but doesn't affect the use of existing trampolines)?
Is this safe for the release branch, in your opinion?

diff --git a/src/comp.c b/src/comp.c
index 188dc6e..ba65837 100644
--- a/src/comp.c
+++ b/src/comp.c
@@ -434,6 +434,13 @@ load_gccjit_if_necessary (bool mandatory)
       gccjit_initialized = init_gccjit_functions ();
       status = gccjit_initialized ? Qt : Qnil;
       Vlibrary_cache = Fcons (Fcons (Qgccjit, status), Vlibrary_cache);
+      /* Disable deferred async compilation and trampoline synthesis
+	 in this session, since libgccjit is not available.  */
+      if (!gccjit_initialized)
+	{
+	  native_comp_deferred_compilation = false;
+	  comp_enable_subr_trampolines = false;
+	}
     }
 
   if (mandatory && !gccjit_initialized)

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

[Corwin Brust]

On Sat, Feb 5, 2022 at 4:10 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Andrea, how about the following patch (which assumes
> comp-enable-subr-trampolines enables and disables only generation of
> new trampolines, but doesn't affect the use of existing trampolines)?
> Is this safe for the release branch, in your opinion?

To be very clear: I'm in no position to comment on how safe this patch
is.  That said...

>
> diff --git a/src/comp.c b/src/comp.c
> index 188dc6e..ba65837 100644
> --- a/src/comp.c
> +++ b/src/comp.c
> @@ -434,6 +434,13 @@ load_gccjit_if_necessary (bool mandatory)
>        gccjit_initialized = init_gccjit_functions ();
>        status = gccjit_initialized ? Qt : Qnil;
>        Vlibrary_cache = Fcons (Fcons (Qgccjit, status), Vlibrary_cache);
> +      /* Disable deferred async compilation and trampoline synthesis
> +        in this session, since libgccjit is not available.  */
> +      if (!gccjit_initialized)
> +       {
> +         native_comp_deferred_compilation = false;
> +         comp_enable_subr_trampolines = false;
> +       }
>      }
>
>    if (mandatory && !gccjit_initialized)

I was able to apply this to the emacs-28 branch and confirm it does
the job.  Thanks due to my elder lad for use of his gaming rig on a
Saturday eve.

The "Patched" result set came from a new set of binary packages[1]
built with this patch.  I also tried a few other things and didn't
spot any obvious breakage.

Drew,
Please LMK if you spot issues with my reproducer and (if you gett a
chance to try) whether you get any different result or if this seems
to solve the issue.

Reproducer:

0. create a folder called c:\emacs
1. download the EL file as linked in Drew's original message to this
thread to c:\emacs
2. download the ELC file attached to that same message to c:\emacs
3. unpack emacs-28.0.91.zip into c:\emacs
4. double click runemacs.exe
5. In scratch, paste in the following sniped and press C-x C-e

  (let ((load-path (append (list "c:/emacs") load-path)))
    (require 'strings))

Patched:

find "strings" at the tail of the *Messages* buffer

Unpatched:

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
"c:/Users/Miko/AppData/Roaming/.emacs.d/eln-cache/2...")
  comp-trampoline-compile(read-buffer)
  comp-subr-trampoline-install(read-buffer)
  defalias(read-buffer #f(compiled-function (prompt &optional default
require-match predicate) #<bytecode -0x12f50ecb110554b3>))
  require(strings)
  (let ((load-path (append (list "c:/emacs") load-path))) (require 'strings))
  (progn (let ((load-path (append (list "c:/emacs") load-path)))
(require 'strings)))
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  command-execute(eval-last-sexp)

[1] Windows binaries Eli's patch, as above:
https://git.sr.ht/~mplscorwin/emacs-w64/tree/master/item/patched

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

[Drew Adams]

> Drew,
> Please LMK if you spot issues with my reproducer and (if you get a
> chance to try) whether you get any different result or if this seems
> to solve the issue.
> 
> Reproducer:
> 
> 0. create a folder called c:\emacs
> 1. download the EL file as linked in Drew's original message to this
> thread to c:\emacs
> 2. download the ELC file attached to that same message to c:\emacs
> 3. unpack emacs-28.0.91.zip into c:\emacs
> 4. double click runemacs.exe
> 5. In scratch, paste in the following sniped and press C-x C-e
> 
>   (let ((load-path (append (list "c:/emacs") load-path)))
>     (require 'strings))

That recipe looks OK to me.

I downloaded this and extracted it:

> [1] Windows binaries Eli's patch, as above:
> https://urldefense.com/v3/__https://git.sr.ht/*mplscorwin/emacs-
> w64/tree/master/item/patched__;fg!!ACWV5N9M2RV99hQ!a802jebRYbd4QTOUJJfQ-
> q7jI0M0gWvrS7qh9s2wEA471JpWCb6Wv84N-Cy_H9W0$

I then used that with my usual init file (which loads
that Emacs 20 ELC file etc.).

I got past the problem of loading library strings.el,
so that problem seems to have been fixed.  Thx.
___

That got me a bit further along in loading my init file,
but I ran into another problem.  Most likely unrelated to
the first problem, and maybe not related to a problematic
Emacs binary or to native compilation.  A guess is that
it's a bug with `define-derived-mode'.  I mention it FYI.

This is the top of the backtrace stack.  An error is
raised when it tries to load library bookmark+.elc.

Debugger entered--Lisp error: (void-variable mode)
  (derived-mode-abbrev-table-name mode)
  (define-abbrev-table (derived-mode-abbrev-table-name mode) nil)
  (progn (define-abbrev-table (derived-mode-abbrev-table-name mode) nil) (make-abbrev-table))
  (defvar bookmark-show-annotation-mode-abbrev-table (progn (define-abbrev-table (derived-mode-abbrev-table-name mode) nil) (make-abbrev-table)) "Abbrev table for bookmark-show-annotation-mode.")
  eval((defvar bookmark-show-annotation-mode-abbrev-table (progn (define-abbrev-table (derived-mode-abbrev-table-name mode) nil) (make-abbrev-table)) "Abbrev table for bookmark-show-annotation-mode."))
  derived-mode-init-mode-variables(bookmark-show-annotation-mode)
  byte-code("\301\302\303\304\305\10\306BBB\307BBB!\210\310\311!\210\312\311\313\305#\207" [bmkp-annotation-modes-inherit-from eval progn (when (keymapp bookmark-edit-annotation-mode-map) (set-keymap-parent bookmark-edit-annotation-mode-map nil)) define-derived-mode bookmark-edit-annotation-mode ("Edit Bookmark Annotation" "Mode for editing the annotation of a bookmark.\nWhe...") ((define-key bookmark-edit-annotation-mode-map "\30\21" 'bmkp-show-this-annotation-read-only) (define-key bookmark-edit-annotation-mode-map "\3\203" 'bookmark-send-edited-annotation)) derived-mode-init-mode-variables bookmark-show-annotation-mode put derived-mode-parent] 7)
  require(bookmark+-1)
  byte-code("\300\301\302\303#\210\300\304!\210\300\305!\210\300\306!\210\307\310!\207" [require bookmark+-lit nil t bookmark+-bmu bookmark+-1 bookmark+-key provide bookmark+] 4)
  require(bookmark+ nil t)
...

But starting from runemacs -Q, and just requiring
library bookmark+ loads it with no problem (just
warnings).  There are a lot of other libraries
that get loaded before bookmark+ when I use my
init file, and the bookmark+ code that gets eval'd
when it's loaded is different, depending on which
of those other libraries might have been loaded,
so I'd need to track down what the problem is.

An a priori guess is that the void-variable error
for variable `mode' comes from a change to lexical
binding in some vanilla library (?).  But I don't
see the error when I load bookmark+ from emacs -Q.

This is the code it seems to be complaining about:

(define-derived-mode bookmark-show-annotation-mode
                     bookmark-edit-annotation-mode
    "Show Bookmark Annotation"
  "Mode for displaying the annotation of a bookmark.

\\{bookmark-show-annotation-mode-map}"
  (setq buffer-read-only  t)
  (define-key bookmark-show-annotation-mode-map
              "\C-x\C-q" 'bmkp-edit-this-annotation))

And that immediately follows this:

;; REPLACES ORIGINAL in `bookmark.el'.
;;
;; 1. Derive from value of option
;;    `bmkp-annotation-modes-inherit-from'.
;; 2. First, remove parent map from
;;    `bookmark-edit-annotation-mode-map', so it is derived anew.
;; 3. Corrected typo in doc string: *send-EDITED-*.
;; 4. Need to use `eval', to pick up option value and reset parent keymap.
;; 5. Bind `C-x C-q' to `bmkp-show-this-annotation-read-only'.
;;
;;;###autoload (autoload 'bookmark-edit-annotation-mode "bookmark+")
(eval
 `(progn
   ;; Get rid of default parent, so
   ;; `bmkp-annotation-modes-inherit-from' is used for the map.
   (when (keymapp bookmark-edit-annotation-mode-map)
     (set-keymap-parent bookmark-edit-annotation-mode-map nil))
   (define-derived-mode bookmark-edit-annotation-mode
                        ,bmkp-annotation-modes-inherit-from
       "Edit Bookmark Annotation"
     "Mode for editing the annotation of a bookmark.
When you have finished composing, use `C-c C-M-c'.

\\{bookmark-edit-annotation-mode-map}")
    (define-key bookmark-edit-annotation-mode-map
                "\C-x\C-q"    'bmkp-show-this-annotation-read-only)
    ;; Define this key because Org mode co-opts `C-c C-c' as a prefix key.
    (define-key bookmark-edit-annotation-mode-map
                "\C-c\C-\M-c" 'bookmark-send-edited-annotation)))

Maybe this will ring a bell for someone reading this.
I doubt I'll get far digging into this, without
wasting a lot of time.  I don't think that
`derived-mode-init-mode-variables' is used anywhere
besides ldefs-boot.el and loaddefs.el (that's the
case in Emacs 26.3, at least).  Why its formal
parameter `mode' apparently isn't getting bound to
the value passed, `bookmark-show-annotation-mode',
I don't know.

I got scared for a moment, as I tried to delete
that ELC file to then try again with my init file.
I couldn't delete or rename it.  Same thing with
the other ELC files that had so far been loaded.

Other ELC files, that would normally get loaded
by my init file but which hadn't yet been tried
to load, I could delete or rename.  I couldn't
figure it out at first, but trying to use Windows
Explorer, instead of Dired, to rename bookmark+-1.elc,
I got a message saying

 File in Use:

 The action can't be completed because the file
 is open in GNU Emacs: The extensible self-documenting
 text editor.

(Emacs was only able to tell me that the rename
or deletion failed.)

After closing all the Emacs 28 session I was
able to rename the file.

I then tried again to run Emacs with my init
file, this time with no ELC for bookmark+-1.el.

I got past that `derived-mode-abbrev-table-name'
problem for bookmark+-1.el, but I ran into the
same problem for another library (synonyms.el),
and its ELC is also from Emacs 20.7.

Debugger entered--Lisp error: (void-variable mode)
  (derived-mode-abbrev-table-name mode)
  (define-abbrev-table (derived-mode-abbrev-table-name mode) nil)
  (progn (define-abbrev-table (derived-mode-abbrev-table-name mode) nil) (make-abbrev-table))
  (defvar synonyms-mode-abbrev-table (progn (define-abbrev-table (derived-mode-abbrev-table-name mode) nil) (make-abbrev-table)) "Abbrev table for synonyms-mode.")
  eval((defvar synonyms-mode-abbrev-table (progn (define-abbrev-table (derived-mode-abbrev-table-name mode) nil) (make-abbrev-table)) "Abbrev table for synonyms-mode."))
  derived-mode-init-mode-variables(synonyms-mode)
  byte-code("\300\301!\210\302\301\303\304#\207" [derived-mode-init-mode-variables synonyms-mode put derived-mode-parent text-mode] 4)
  require(synonyms nil t)
  byte-code("\10\303V\203\13\0\304\305\306\217\210\10\303V\203\27\0\307\310\304\311#\210\307\312\304\311#\210\10\303V\2032\0\307\313\304\311#\210\314\315!\2032\0\315 \210..." [emacs-major-version window-system system-type 21 nil (byte-code "\300\301\302\303#\207" [require crosshairs nil t] 4) ((error)) require hl-spotlight t pp-c-l pretty-lambdada fboundp pretty-lambda-for-modes echo-bell da-setup local-lpr local-ps-print printing font-lock-menus featurep 24 font-menus facemenu+ font-lock+ display-graphic-p zoom-frm eval-after-load "info" (if (> emacs-major-version 22) (require 'info+ nil t) (require 'info+20 nil t)) fuzzy-match swiss-move setup-keys replace+ apropos-fn+var lacarte synonyms 20 tool-bar+ "icomplete" (require 'icomplete+ nil t) "diff" (require 'diff+ nil t) diff-mode- diff-mode (require 'diff+20 nil t) ediff+ find-dired+ dired+ windows-nt ...] 5)
  require(start)

And if I just do `M-x load-library synonyms.elc'
then I get the error message in the echo area:

 Symbol's value as variable is void: mode

This is the use of `define-derived-mode' in
synonyms.el (I've elided the doc-string text):

(define-derived-mode synonyms-mode text-mode "Synonyms"
  "..."
  (modify-syntax-entry ?- "w" synonyms-mode-syntax-table)
  (modify-syntax-entry ?1 "w" synonyms-mode-syntax-table)
  (modify-syntax-entry ?2 "w" synonyms-mode-syntax-table)
  (modify-syntax-entry ?3 "w" synonyms-mode-syntax-table)
  (modify-syntax-entry ?9 "w" synonyms-mode-syntax-table)
  (modify-syntax-entry ?0 "w" synonyms-mode-syntax-table)
  (modify-syntax-entry ?$ "w" synonyms-mode-syntax-table)
  (buffer-disable-undo)
  (setq fill-column  synonyms-fill-column)
  (set (make-local-variable 'transient-mark-mode) t))

I don't feel like digging deeper into this.
Hopefully someone knowledgeable can figure out
what the problem is from my description here.

___

I'll just mention that this is the first time I've
not been able to just immediately use a Windows
binary for Emacs.  Never had an error raised before
when just loading my init file.  And that's still
the case, for all releases starting with Emacs 20.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: Andrea Corallo <akrl@sdf.org>,
>         "H. Dieter Wilhelm"
> 	<dieter@duenenhof-wilhelm.de>,
>         Emacs developers <emacs-devel@gnu.org>
> Date: Sun, 6 Feb 2022 06:57:57 +0000
> 
> And if I just do `M-x load-library synonyms.elc'
> then I get the error message in the echo area:
> 
>  Symbol's value as variable is void: mode
> 
> This is the use of `define-derived-mode' in
> synonyms.el (I've elided the doc-string text):
> 
> (define-derived-mode synonyms-mode text-mode "Synonyms"
>   "..."
>   (modify-syntax-entry ?- "w" synonyms-mode-syntax-table)
>   (modify-syntax-entry ?1 "w" synonyms-mode-syntax-table)
>   (modify-syntax-entry ?2 "w" synonyms-mode-syntax-table)
>   (modify-syntax-entry ?3 "w" synonyms-mode-syntax-table)
>   (modify-syntax-entry ?9 "w" synonyms-mode-syntax-table)
>   (modify-syntax-entry ?0 "w" synonyms-mode-syntax-table)
>   (modify-syntax-entry ?$ "w" synonyms-mode-syntax-table)
>   (buffer-disable-undo)
>   (setq fill-column  synonyms-fill-column)
>   (set (make-local-variable 'transient-mark-mode) t))
> 
> I don't feel like digging deeper into this.
> Hopefully someone knowledgeable can figure out
> what the problem is from my description here.

The only way forward is for you to prepare a complete reproduction
recipe, starting from "emacs -Q", then someone could look into what is
going on there.

> I'll just mention that this is the first time I've
> not been able to just immediately use a Windows
> binary for Emacs.  Never had an error raised before
> when just loading my init file.  And that's still
> the case, for all releases starting with Emacs 20.

This is a pretest.  Problems are quite possible and expected.  That's
why we have pretests in the first place.

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

[Drew Adams]

> The only way forward is for you to prepare a complete reproduction
> recipe, starting from "emacs -Q", then someone could look into what is
> going on there.

Certainly that might be ideal.  Thankfully
it's not necessarily the only way forward.

This is a pretest.  Hopefully Emacs will be
further tested before being released.

Nothing prevents ignoring the feedback I've
spent time digging up so far, of course.

It was offered with hope that it might help,
not as a negative statement about the state
of Emacs 28 development.

I don't expect to be able to use Emacs 28
any time soon with my general setup, even
after it's well tested and released.

I did hope Emacs developers might appreciate
my offering some initial feedback of trying
to use the Windows binary, regardless of how
helpful that feedback might prove to be in
practice.  I have no idea how helpful it
might be, a priori.

> > I'll just mention that this is the first time I've
> > not been able to just immediately use a Windows
> > binary for Emacs.  Never had an error raised before
> > when just loading my init file.  And that's still
> > the case, for all releases starting with Emacs 20.
> 
> This is a pretest.  Problems are quite possible and 
> expected.  That's why we have pretests in the first place.

I'm well aware that this is a pretest.  I
have no expectation that it works like a
release.  I only related the fact that my
experience with this pretest is different
from my experience with previous pretests.

I've used many Emacs pretests, and this is
the first time what I mentioned is true.
Not saying that implies anything - just
saying.

Take it as perhaps one tiny bit of feedback
for where we might be in the release-prep
cycle.  Or not.  FWIW.  If it doesn't help
at all, fine.

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

[Eli Zaretskii]

Ping!

Andrea, can you please look into this?

> Date: Sat, 05 Feb 2022 12:10:34 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, drew.adams@oracle.com,
>  emacs-devel@gnu.org
> 
> > Date: Sat, 05 Feb 2022 09:25:56 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
> > 
> > > 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)
> > 
> > Andrea, is this expected on a machine that lacks libgccjit?  Under
> > what conditions would loading a .elc file trigger native-compilation
> > of a trampoline?
> > 
> > If this is expected, I'd prefer that we detected the unavailability of
> > libgccjit earlier, and avoided the attempt to compile a trampoline in
> > the first place.  Can this be done safely enough to make the change on
> > the release branch?
> 
> Andrea, how about the following patch (which assumes
> comp-enable-subr-trampolines enables and disables only generation of
> new trampolines, but doesn't affect the use of existing trampolines)?
> Is this safe for the release branch, in your opinion?
> 
> diff --git a/src/comp.c b/src/comp.c
> index 188dc6e..ba65837 100644
> --- a/src/comp.c
> +++ b/src/comp.c
> @@ -434,6 +434,13 @@ load_gccjit_if_necessary (bool mandatory)
>        gccjit_initialized = init_gccjit_functions ();
>        status = gccjit_initialized ? Qt : Qnil;
>        Vlibrary_cache = Fcons (Fcons (Qgccjit, status), Vlibrary_cache);
> +      /* Disable deferred async compilation and trampoline synthesis
> +	 in this session, since libgccjit is not available.  */
> +      if (!gccjit_initialized)
> +	{
> +	  native_comp_deferred_compilation = false;
> +	  comp_enable_subr_trampolines = false;
> +	}
>      }
>  
>    if (mandatory && !gccjit_initialized)
> 
> 

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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

> Ping!
>
> Andrea, can you please look into this?

Hi Eli,

sorry if I missed this, this thread triggered numerous score rules in my
gnus since the beginning but after a while I assumed it did not required
my attention...

>> Date: Sat, 05 Feb 2022 12:10:34 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, drew.adams@oracle.com,
>>  emacs-devel@gnu.org
>> 
>> > Date: Sat, 05 Feb 2022 09:25:56 +0200
>> > From: Eli Zaretskii <eliz@gnu.org>
>> > Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
>> > 
>> > > 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)
>> > 
>> > Andrea, is this expected on a machine that lacks libgccjit?

ATM yes I think so.

>> > Under
>> > what conditions would loading a .elc file trigger native-compilation
>> > of a trampoline?

A trampoline compilation is triggered every time a primitive function is
redefined or advised.  So yeah if a primitive function is redefined in a
.elc being loaded this will trigger the trampoline machinery.

>> > If this is expected, I'd prefer that we detected the unavailability of
>> > libgccjit earlier, and avoided the attempt to compile a trampoline in
>> > the first place.

I see, but note that if we cannot compile a trampoline (and this is not
available already) indeed we cannot install it.  As a consequence we
cannot guarantee that the primitive function being redefined will take
effect in other Lisp code previously native compiled (in C code it will
not take effect anyway).

>> > Can this be done safely enough to make the change on
>> > the release branch?
>> 
>> Andrea, how about the following patch (which assumes
>> comp-enable-subr-trampolines enables and disables only generation of
>> new trampolines, but doesn't affect the use of existing trampolines)?
>> Is this safe for the release branch, in your opinion?
>> 
>> diff --git a/src/comp.c b/src/comp.c
>> index 188dc6e..ba65837 100644
>> --- a/src/comp.c
>> +++ b/src/comp.c
>> @@ -434,6 +434,13 @@ load_gccjit_if_necessary (bool mandatory)
>>        gccjit_initialized = init_gccjit_functions ();
>>        status = gccjit_initialized ? Qt : Qnil;
>>        Vlibrary_cache = Fcons (Fcons (Qgccjit, status), Vlibrary_cache);
>> +      /* Disable deferred async compilation and trampoline synthesis
>> +	 in this session, since libgccjit is not available.  */
>> +      if (!gccjit_initialized)
>> +	{
>> +	  native_comp_deferred_compilation = false;
>> +	  comp_enable_subr_trampolines = false;
>> +	}
>>      }
>>  
>>    if (mandatory && !gccjit_initialized)

I'm wondering if doing this here is not too late.  Say loading we try to
redefine a primitive:

- In `fset' we trigger `comp-subr-trampoline-install'

- In `comp-subr-trampoline-install' we call `comp-trampoline-compile'

- This is using `comp--native-compile'

- This is calling `comp-ensure-native-compiler'

- This will call `native-comp-available-p' that will set
  'native_comp_deferred_compilation' and
  'native_comp_deferred_compilation'.  But at this point we will still
  raise the error because of `native-comp-available-p' return value.

This assuming I'm not missing something and `native-comp-available-p'
doesn't gets called earlier during the stratup process.

Wouldn't be better to call explicitly `native-comp-available-p' from
startup.el and set the two variables from there?

Best Regards

  Andrea

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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
> Date: Wed, 09 Feb 2022 21:03:39 +0000
> 
> Wouldn't be better to call explicitly `native-comp-available-p' from
> startup.el and set the two variables from there?

Fine with me.  Could you suggest a good place for that call?

And I understand that you are suggesting that _in_addition_ to the
patch I proposed, right?

Thanks.

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

[Andrea Corallo]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
>> Date: Wed, 09 Feb 2022 21:03:39 +0000
>> 
>> Wouldn't be better to call explicitly `native-comp-available-p' from
>> startup.el and set the two variables from there?
>
> Fine with me.  Could you suggest a good place for that call?

I'd propose the following patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-startup.el-normal-top-level-Disable-native-comp.patch --]
[-- Type: text/x-diff, Size: 857 bytes --]

From 4bdbf3c76394e6d83f4a2bbb582ae0549674512c Mon Sep 17 00:00:00 2001
From: Andrea Corallo <akrl@sdf.org>
Date: Thu, 10 Feb 2022 09:46:31 +0100
Subject: [PATCH] * lisp/startup.el (normal-top-level): Disable native-comp if
 not available

---
 lisp/startup.el | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lisp/startup.el b/lisp/startup.el
index 71e492e3b4..cccaa90e9c 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -537,6 +537,10 @@ normal-top-level
     (setq user-emacs-directory
 	  (startup--xdg-or-homedot startup--xdg-config-home-emacs nil))
 
+    (unless (native-comp-available-p)
+      (setq native-comp-deferred-compilation nil
+            comp-enable-subr-trampolines nil))
+
     (when (featurep 'native-compile)
       ;; Form `native-comp-eln-load-path'.
       (let ((path-env (getenv "EMACSNATIVELOADPATH")))
-- 
2.20.1


[-- Attachment #3: Type: text/plain, Size: 550 bytes --]


This way we set the two variables just before doing the
`native-comp-eln-load-path' job.  So essentially before the native
compiler is usable.

*Also* I'm now wondering if we shouldn't rename
 `comp-enable-subr-trampolines' into
 `native-comp-enable-subr-trampolines' (if it's not to late...)

> And I understand that you are suggesting that _in_addition_ to the
> patch I proposed, right?

I think my change should be sufficient, maybe you see a reason why we
should set these two every time we pass in `native-comp-available-p'?

Thanks

  Andrea

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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
> Date: Thu, 10 Feb 2022 08:56:50 +0000
> 
> 
> [1:text/plain Hide]
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andrea Corallo <akrl@sdf.org>
> >> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
> >> Date: Wed, 09 Feb 2022 21:03:39 +0000
> >> 
> >> Wouldn't be better to call explicitly `native-comp-available-p' from
> >> startup.el and set the two variables from there?
> >
> > Fine with me.  Could you suggest a good place for that call?
> 
> I'd propose the following patch:

Fine with me, please install on the release branch.  But please add
there a comment explaining why we do this, and mention that it's for
MS-Windows (you can take the text from the comment I wrote for my
comp.c patch, which will now not be needed).

Thanks.

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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
>> Date: Thu, 10 Feb 2022 08:56:50 +0000
>> 
>> 
>> [1:text/plain Hide]
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Andrea Corallo <akrl@sdf.org>
>> >> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
>> >> Date: Wed, 09 Feb 2022 21:03:39 +0000
>> >> 
>> >> Wouldn't be better to call explicitly `native-comp-available-p' from
>> >> startup.el and set the two variables from there?
>> >
>> > Fine with me.  Could you suggest a good place for that call?
>> 
>> I'd propose the following patch:
>
> Fine with me, please install on the release branch.  But please add
> there a comment explaining why we do this, and mention that it's for
> MS-Windows (you can take the text from the comment I wrote for my
> comp.c patch, which will now not be needed).

Done with 202d3be873.

PS I tried to merge emacs-28 into master using gitmerge.el as suggested
in git-workflow as I suspected a conflict there that I wanted to solve
myself, but it says "nothing to merge".  Not sure if I'm doing something
wrong.

Thanks

  Andrea

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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
> Date: Thu, 10 Feb 2022 13:36:10 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Fine with me, please install on the release branch.  But please add
> > there a comment explaining why we do this, and mention that it's for
> > MS-Windows (you can take the text from the comment I wrote for my
> > comp.c patch, which will now not be needed).
> 
> Done with 202d3be873.

Thanks.

> PS I tried to merge emacs-28 into master using gitmerge.el as suggested
> in git-workflow as I suspected a conflict there that I wanted to solve
> myself, but it says "nothing to merge".  Not sure if I'm doing something
> wrong.

I merged that change, but for the future: what exactly did you do, and
in particular did you remember to switch to the master branch and do a
"git pull" in master, before invoking "gitmerge"?

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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
>> Date: Thu, 10 Feb 2022 13:36:10 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Fine with me, please install on the release branch.  But please add
>> > there a comment explaining why we do this, and mention that it's for
>> > MS-Windows (you can take the text from the comment I wrote for my
>> > comp.c patch, which will now not be needed).
>> 
>> Done with 202d3be873.
>
> Thanks.
>
>> PS I tried to merge emacs-28 into master using gitmerge.el as suggested
>> in git-workflow as I suspected a conflict there that I wanted to solve
>> myself, but it says "nothing to merge".  Not sure if I'm doing something
>> wrong.
>
> I merged that change, but for the future: what exactly did you do, and
> in particular did you remember to switch to the master branch and do a
> "git pull" in master, before invoking "gitmerge"?

I did what's described in git-workflow, so yes I had master checked out
and I pulled before trying.  The only difference is that haven't started
a fresh emacs but loaded gitmerge.el in my current session.  Next time
I'll try with a fresh session and maybe with -Q.

Anyway I was thinking if it wouldn't be correct to emit also a warning
if libgccjit is not available.  This condition could prevent some
package to work as expected (ex evil-mode IIRC) so might be worth to
inform the user that and emacs compiled with native-comp is being run
without libgccjit being available.

In case we decide is worth if we agree on the message I'll be happy to
prepare the patch.

Best Regards

  Andrea

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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
> Date: Thu, 10 Feb 2022 18:34:22 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> PS I tried to merge emacs-28 into master using gitmerge.el as suggested
> >> in git-workflow as I suspected a conflict there that I wanted to solve
> >> myself, but it says "nothing to merge".  Not sure if I'm doing something
> >> wrong.
> >
> > I merged that change, but for the future: what exactly did you do, and
> > in particular did you remember to switch to the master branch and do a
> > "git pull" in master, before invoking "gitmerge"?
> 
> I did what's described in git-workflow, so yes I had master checked out
> and I pulled before trying.  The only difference is that haven't started
> a fresh emacs but loaded gitmerge.el in my current session.  Next time
> I'll try with a fresh session and maybe with -Q.

What was the default-directory when you invoked "M-x gitmerge"?  It
should be the Emacs repository, and Emacs should know that the current
branch in that directory is "master".

Starting a new Emacs session is indeed better.  (I also have separate
directories for master and the release branch, so for me changing the
default-directory ("M-x cd") also means I'm sure gitmerge will use the
correct branch.)

> Anyway I was thinking if it wouldn't be correct to emit also a warning
> if libgccjit is not available.  This condition could prevent some
> package to work as expected (ex evil-mode IIRC) so might be worth to
> inform the user that and emacs compiled with native-comp is being run
> without libgccjit being available.

I'm not sure I see the usefulness of such a warning.  If Emacs works
correctly regardless, the warning could annoy.  So I tend to think we
should introduce the warning only if enough users complain that Emacs
silently does something they'd prefer to know about.

Thanks.

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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
>> Date: Thu, 10 Feb 2022 18:34:22 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> PS I tried to merge emacs-28 into master using gitmerge.el as suggested
>> >> in git-workflow as I suspected a conflict there that I wanted to solve
>> >> myself, but it says "nothing to merge".  Not sure if I'm doing something
>> >> wrong.
>> >
>> > I merged that change, but for the future: what exactly did you do, and
>> > in particular did you remember to switch to the master branch and do a
>> > "git pull" in master, before invoking "gitmerge"?
>> 
>> I did what's described in git-workflow, so yes I had master checked out
>> and I pulled before trying.  The only difference is that haven't started
>> a fresh emacs but loaded gitmerge.el in my current session.  Next time
>> I'll try with a fresh session and maybe with -Q.
>
> What was the default-directory when you invoked "M-x gitmerge"?  It
> should be the Emacs repository, and Emacs should know that the current
> branch in that directory is "master".

Okay thanks next time I'll verify that as well.

> Starting a new Emacs session is indeed better.  (I also have separate
> directories for master and the release branch, so for me changing the
> default-directory ("M-x cd") also means I'm sure gitmerge will use the
> correct branch.)
>
>> Anyway I was thinking if it wouldn't be correct to emit also a warning
>> if libgccjit is not available.  This condition could prevent some
>> package to work as expected (ex evil-mode IIRC) so might be worth to
>> inform the user that and emacs compiled with native-comp is being run
>> without libgccjit being available.
>
> I'm not sure I see the usefulness of such a warning.  If Emacs works
> correctly regardless, the warning could annoy.  So I tend to think we
> should introduce the warning only if enough users complain that Emacs
> silently does something they'd prefer to know about.

I think it might be useful for two reasons:

1- let the user know that a native compiled Emacs is being run without
   access to libgccjit, not only it might not function as expected but
   most likely I guess that if the user compiled a native compiled Emacs
   he wants to have it working with native code.  So in general I guess
   it might be informative.

2- help us identifying the issue when a bug is opened because of it, if
   we suspect that's the problem we can ask the user to have a look to
   the warnings.

But indeed I'm not sure it's worth of so I asked.

An alternative to point two would be having a trace of this in M-x
report-emacs-bug.

Another alternative to the problem on MS-Windows would be not to
optimize calls to primitive functions and have them go always through
funcall.  This is very easy compiler wise but has probably too drastic
as brings a performance penalty.

Best Regards

  Andrea

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

[Andrea Corallo]

Andrea Corallo <akrl@sdf.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:

[...]

>>> Anyway I was thinking if it wouldn't be correct to emit also a warning
>>> if libgccjit is not available.  This condition could prevent some
>>> package to work as expected (ex evil-mode IIRC) so might be worth to
>>> inform the user that and emacs compiled with native-comp is being run
>>> without libgccjit being available.
>>
>> I'm not sure I see the usefulness of such a warning.  If Emacs works
>> correctly regardless, the warning could annoy.  So I tend to think we
>> should introduce the warning only if enough users complain that Emacs
>> silently does something they'd prefer to know about.
>
> I think it might be useful for two reasons:
>
> 1- let the user know that a native compiled Emacs is being run without
>    access to libgccjit, not only it might not function as expected but
>    most likely I guess that if the user compiled a native compiled Emacs
>    he wants to have it working with native code.  So in general I guess
>    it might be informative.
>
> 2- help us identifying the issue when a bug is opened because of it, if
>    we suspect that's the problem we can ask the user to have a look to
>    the warnings.
>
> But indeed I'm not sure it's worth of so I asked.
>
> An alternative to point two would be having a trace of this in M-x
> report-emacs-bug.

Thinking about I think this might be a good idea anyway.

  Andrea

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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
> Date: Fri, 11 Feb 2022 09:21:52 +0000
> 
> Andrea Corallo <akrl@sdf.org> writes:
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> 
> [...]
> 
> >>> Anyway I was thinking if it wouldn't be correct to emit also a warning
> >>> if libgccjit is not available.  This condition could prevent some
> >>> package to work as expected (ex evil-mode IIRC) so might be worth to
> >>> inform the user that and emacs compiled with native-comp is being run
> >>> without libgccjit being available.
> >>
> >> I'm not sure I see the usefulness of such a warning.  If Emacs works
> >> correctly regardless, the warning could annoy.  So I tend to think we
> >> should introduce the warning only if enough users complain that Emacs
> >> silently does something they'd prefer to know about.
> >
> > I think it might be useful for two reasons:
> >
> > 1- let the user know that a native compiled Emacs is being run without
> >    access to libgccjit, not only it might not function as expected but
> >    most likely I guess that if the user compiled a native compiled Emacs
> >    he wants to have it working with native code.  So in general I guess
> >    it might be informative.
> >
> > 2- help us identifying the issue when a bug is opened because of it, if
> >    we suspect that's the problem we can ask the user to have a look to
> >    the warnings.
> >
> > But indeed I'm not sure it's worth of so I asked.
> >
> > An alternative to point two would be having a trace of this in M-x
> > report-emacs-bug.
> 
> Thinking about I think this might be a good idea anyway.

I agree.  Would you mind proposing a patch?

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

[Andrea Corallo]

[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
>> Date: Fri, 11 Feb 2022 09:21:52 +0000
>> 
>> Andrea Corallo <akrl@sdf.org> writes:
>> 
>> > Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> [...]
>> 
>> >>> Anyway I was thinking if it wouldn't be correct to emit also a warning
>> >>> if libgccjit is not available.  This condition could prevent some
>> >>> package to work as expected (ex evil-mode IIRC) so might be worth to
>> >>> inform the user that and emacs compiled with native-comp is being run
>> >>> without libgccjit being available.
>> >>
>> >> I'm not sure I see the usefulness of such a warning.  If Emacs works
>> >> correctly regardless, the warning could annoy.  So I tend to think we
>> >> should introduce the warning only if enough users complain that Emacs
>> >> silently does something they'd prefer to know about.
>> >
>> > I think it might be useful for two reasons:
>> >
>> > 1- let the user know that a native compiled Emacs is being run without
>> >    access to libgccjit, not only it might not function as expected but
>> >    most likely I guess that if the user compiled a native compiled Emacs
>> >    he wants to have it working with native code.  So in general I guess
>> >    it might be informative.
>> >
>> > 2- help us identifying the issue when a bug is opened because of it, if
>> >    we suspect that's the problem we can ask the user to have a look to
>> >    the warnings.
>> >
>> > But indeed I'm not sure it's worth of so I asked.
>> >
>> > An alternative to point two would be having a trace of this in M-x
>> > report-emacs-bug.
>> 
>> Thinking about I think this might be a good idea anyway.
>
> I agree.  Would you mind proposing a patch?

Sure, something like:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-mail-emacsbug.el-report-emacs-bug-Report-libgcc.patch --]
[-- Type: text/x-diff, Size: 904 bytes --]

From ffa9772fa5b04f916d6b49668dbd93b1743f6c18 Mon Sep 17 00:00:00 2001
From: Andrea Corallo <akrl@sdf.org>
Date: Fri, 11 Feb 2022 15:00:57 +0100
Subject: [PATCH] * lisp/mail/emacsbug.el (report-emacs-bug): Report libgccjit
 status.

---
 lisp/mail/emacsbug.el | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lisp/mail/emacsbug.el b/lisp/mail/emacsbug.el
index f5559e39f6..759d8c11b5 100644
--- a/lisp/mail/emacsbug.el
+++ b/lisp/mail/emacsbug.el
@@ -304,6 +304,9 @@ report-emacs-bug
     (emacs-bug--system-description)
     (insert "Configured features:\n" system-configuration-features "\n\n")
     (fill-region (line-beginning-position -1) (point))
+    (when (and (featurep 'native-compile)
+               (null (native-comp-available-p)))
+      (insert "NATIVE_COMP present but libgccjit not available\n\n"))
     (insert "Important settings:\n")
     (mapc
      (lambda (var)
-- 
2.20.1


[-- Attachment #3: Type: text/plain, Size: 566 bytes --]


The output (if necessary) is placed after NATIVE_COMP feature is
mentioned, ex:

====================

Configured using:
 'configure --without-x --with-native-compilation'

Configured features:
DBUS GMP GNUTLS LIBSELINUX MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER
SECCOMP SOUND THREADS XIM ZLIB

NATIVE_COMP present but libgccjit not available

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

====================

Not sure if we like to place it elsewhere and/or if we have a better
message to be displayed.

Thanks

  Andrea

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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
> Date: Fri, 11 Feb 2022 14:16:37 +0000
> 
> +    (when (and (featurep 'native-compile)
> +               (null (native-comp-available-p)))
> +      (insert "NATIVE_COMP present but libgccjit not available\n\n"))

Maybe enclose this in parentheses, but otherwise please install, and
thanks.

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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
>> Date: Fri, 11 Feb 2022 14:16:37 +0000
>> 
>> +    (when (and (featurep 'native-compile)
>> +               (null (native-comp-available-p)))
>> +      (insert "NATIVE_COMP present but libgccjit not available\n\n"))
>
> Maybe enclose this in parentheses, but otherwise please install, and
> thanks.

done as 6015d5e8ee, thanks

  Andrea

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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
> Date: Fri, 11 Feb 2022 09:16:25 +0000
> 
> >> Anyway I was thinking if it wouldn't be correct to emit also a warning
> >> if libgccjit is not available.  This condition could prevent some
> >> package to work as expected (ex evil-mode IIRC) so might be worth to
> >> inform the user that and emacs compiled with native-comp is being run
> >> without libgccjit being available.
> >
> > I'm not sure I see the usefulness of such a warning.  If Emacs works
> > correctly regardless, the warning could annoy.  So I tend to think we
> > should introduce the warning only if enough users complain that Emacs
> > silently does something they'd prefer to know about.
> 
> I think it might be useful for two reasons:
> 
> 1- let the user know that a native compiled Emacs is being run without
>    access to libgccjit, not only it might not function as expected but
>    most likely I guess that if the user compiled a native compiled Emacs
>    he wants to have it working with native code.  So in general I guess
>    it might be informative.

This is unlikely to happen if the user has libgccjit installed: if it
is found when building Emacs, it will most probably be also found when
running it.

So the warning will mostly show when the user installed Emacs built by
someone else.  In which case, the user already made the decision not
to install libgccjit, so warning the user about that would be in
many/most cases redundant.

> 2- help us identifying the issue when a bug is opened because of it, if
>    we suspect that's the problem we can ask the user to have a look to
>    the warnings.

This could be a valuable indication, but if so, I think it's
report-emacs-bug that should detect and report it, as part of the
system configuration description, as you suggest.

> Another alternative to the problem on MS-Windows would be not to
> optimize calls to primitive functions and have them go always through
> funcall.  This is very easy compiler wise but has probably too drastic
> as brings a performance penalty.

Right.

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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
>> Date: Fri, 11 Feb 2022 09:16:25 +0000
>> 
>> >> Anyway I was thinking if it wouldn't be correct to emit also a warning
>> >> if libgccjit is not available.  This condition could prevent some
>> >> package to work as expected (ex evil-mode IIRC) so might be worth to
>> >> inform the user that and emacs compiled with native-comp is being run
>> >> without libgccjit being available.
>> >
>> > I'm not sure I see the usefulness of such a warning.  If Emacs works
>> > correctly regardless, the warning could annoy.  So I tend to think we
>> > should introduce the warning only if enough users complain that Emacs
>> > silently does something they'd prefer to know about.
>> 
>> I think it might be useful for two reasons:
>> 
>> 1- let the user know that a native compiled Emacs is being run without
>>    access to libgccjit, not only it might not function as expected but
>>    most likely I guess that if the user compiled a native compiled Emacs
>>    he wants to have it working with native code.  So in general I guess
>>    it might be informative.
>
> This is unlikely to happen if the user has libgccjit installed: if it
> is found when building Emacs, it will most probably be also found when
> running it.

Because is unlikely is suspect might be of interest in this case.

> So the warning will mostly show when the user installed Emacs built by
> someone else.  In which case, the user already made the decision not
> to install libgccjit, so warning the user about that would be in
> many/most cases redundant.

How do we know the user made this decision intentionally?

Best Regards

  Andrea

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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
> Date: Fri, 11 Feb 2022 14:18:45 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 1- let the user know that a native compiled Emacs is being run without
> >>    access to libgccjit, not only it might not function as expected but
> >>    most likely I guess that if the user compiled a native compiled Emacs
> >>    he wants to have it working with native code.  So in general I guess
> >>    it might be informative.
> >
> > This is unlikely to happen if the user has libgccjit installed: if it
> > is found when building Emacs, it will most probably be also found when
> > running it.
> 
> Because is unlikely is suspect might be of interest in this case.

Maybe so, but we don't provide any similar diagnostics for any other
optional DLL.

> > So the warning will mostly show when the user installed Emacs built by
> > someone else.  In which case, the user already made the decision not
> > to install libgccjit, so warning the user about that would be in
> > many/most cases redundant.
> 
> How do we know the user made this decision intentionally?

We assume they read the documentation, which tells them about the
optional libraries.

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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
>> Date: Fri, 11 Feb 2022 14:18:45 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> 1- let the user know that a native compiled Emacs is being run without
>> >>    access to libgccjit, not only it might not function as expected but
>> >>    most likely I guess that if the user compiled a native compiled Emacs
>> >>    he wants to have it working with native code.  So in general I guess
>> >>    it might be informative.
>> >
>> > This is unlikely to happen if the user has libgccjit installed: if it
>> > is found when building Emacs, it will most probably be also found when
>> > running it.
>> 
>> Because is unlikely is suspect might be of interest in this case.
>
> Maybe so, but we don't provide any similar diagnostics for any other
> optional DLL.

I see, that's why I was in doubt, but this is perhaps more critical as
Emacs may not function as expected.

>> > So the warning will mostly show when the user installed Emacs built by
>> > someone else.  In which case, the user already made the decision not
>> > to install libgccjit, so warning the user about that would be in
>> > many/most cases redundant.
>> 
>> How do we know the user made this decision intentionally?
>
> We assume they read the documentation, which tells them about the
> optional libraries.

Say the user did, but for some reason Emacs can't find libgccjit even if
the user thought it's installed correctly.  How the user is supposed to
detect this if we made it all transparent?

Thanks

  Andrea

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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
> Date: Fri, 11 Feb 2022 14:44:05 +0000
> 
> Say the user did, but for some reason Emacs can't find libgccjit even if
> the user thought it's installed correctly.

This is highly unlikely.  I don't even understand how it could happen.

> How the user is supposed to detect this if we made it all
> transparent?

The user will eventually see that JIT native compilation doesn't
happen and Lisp packages used by Emacs aren't being compiled.

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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
>> Date: Fri, 11 Feb 2022 14:44:05 +0000
>> 
>> Say the user did, but for some reason Emacs can't find libgccjit even if
>> the user thought it's installed correctly.
>
> This is highly unlikely.  I don't even understand how it could happen.

Dunno I know nothing about Windows, but maybe there's some env var that
needs to point where the dynamic linker can find the dll and this can be
missconfigured?

>> How the user is supposed to detect this if we made it all
>> transparent?
>
> The user will eventually see that JIT native compilation doesn't
> happen and Lisp packages used by Emacs aren't being compiled.

If he pays attention to that and he verifies, otherwise the system is
designed to be quite transparent.

Best Regards

  Andrea

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

[Corwin Brust]

o/ Dieter

On Thu, Feb 10, 2022 at 7:36 AM Andrea Corallo <akrl@sdf.org> wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
> >
> > Fine with me, please install on the release branch.  But please add
> > there a comment explaining why we do this, and mention that it's for
> > MS-Windows (you can take the text from the comment I wrote for my
> > comp.c patch, which will now not be needed).
>
> Done with 202d3be873.

This change is now reflected in the binaries in the
with-native-compilation folder of the scratch repo[1][2] - I will
update alpha with this set unless I've heard back that I shouldn't (or
that I should wait) within a day or two.

From my limited testing, they look good.  I tried the ERT tests from
etc/w32-feature.el as well as Drew's original report scenario.

[1] clone or www - https://git.sr.ht/~mplscorwin/emacs-w64
[2] wget or www -
https://git.sr.ht/~mplscorwin/emacs-w64/blob/master/with-native-compilation/emacs-28.0.91.zip

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.