bug#71801: emacs 29.4 windows binaries

[Eli Zaretskii <eliz@gnu.org>]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "corwin@bru.st" <corwin@bru.st>,
>         "tclwarrior@gmail.com"
> 	<tclwarrior@gmail.com>,
>         "71801@debbugs.gnu.org" <71801@debbugs.gnu.org>
> Date: Sat, 6 Jul 2024 15:33:49 +0000
> 
> > > > You need to install GNU Binutils, which is where as.exe, the GNU
> > > > assembler, comes from.
> > >
> > > Why?
> > 
> > It's needed for JIT native compilation of Lisp.
> 
> Until now, there has been no requirement
> to have anything that's needed to support
> native compilation.  Until now, Emacs just
> ignored native compilation if the local
> "infrastructure" to support it was missing.
> 
> That approach was good.

As Corwin explained already, he made a packaging mistake, whereby the
"infrastructure" in support of native compilation was half-present and
half-absent.

> > > > > I haven't noticed other problems yet (with -Q), but
> > > > > is the continual emission of that warning expected?
> > > >
> > > > Yes.
> > >
> > > Why is that a good thing to do?
> > 
> > It isn't supposed to happen in a working Emacs installation.
> 
> I see.  You mean the warning itself, or
> the need for a user to have whatever's
> needed to support native compilation?

Neither.  What isn't supposed to happen is that you have GCC and
libgccjit, but not Binutils.  You should either have all of them, or
none, then the silent fallback on byte-compiled code will work.  What
happened in your case is that Emacs found libgccjit, so it decided the
native compilation was supported, but libgccjit choked when it
actually tried to compile Lisp to native code.

> > Its absence is like the absence of dired.el/dired.elc: it should not
> > happen.  So by default Emacs warns about it every time it wants to
> > natively compile a file.
> 
> So is it only a problem with the Emacs build,
> or is Emacs considering that the user's
> context is inadequate and the user needs to
> do something to remedy that?

It depends on the user.  If the user is the one who set up the
development and run-time environment, then the user should fix it to
be fully operable.  If the user just installed a binary distro, he/she
should take this up to whoever produced the distro.

> > > > > Clicking that black, square icon pops up this
> > > > > question as a menu:
> > > > >
> > > > >   Suppress `comp' warnings?
> > > > >   _________________________
> > > > >
> > > > >   Yes, Ignore `Comp' Warnings Completely
> > > > >   No, Just Disable Showing Them
> > > > >   Quit And Do Nothing
> > > > >
> > > > > I have no idea what any of that means.
> > > >
> > > > It allows you to disable these warnings, so that they don't annoy you.
> > >
> > > Sure.  But _what are_ `Comp' warnings?
> > 
> > They are the warnings labeled 'comp', as in the warning you've shown.
> 
> So just as meaningless as if the label were 'foobar'
> or 'guess-what-this-means'.

No, not just as meaningless.

> > > How is someone to know whether they might want to (or need to)
> > > ignore, disable, or do nothing?
> > 
> > By reading the warnings, understanding what they say and mean, and
> > deciding what to do with them.  It's a user decision.
> 
> So this is a user problem, not an Emacs build
> problem?  (That's what user warnings are for.)

It is a problem with the Emacs installation.  Who should fix it
depends on how and by whom Emacs was built and installed.  Emacs
itself cannot know that.

> If so, that's the problem with the warning:
> it's not comprehensible to many (most?) users.
> The "user decision" can't be based on any real
> understanding of what's involved (in this case).

Users who don't understand the warning will do what they always do:
search the Internet or ask on known forums.

> > Isn't it you that always requests to let the
> > users the freedom of deciding how to
> > deal with non-trivial situations?
> 
> Not by not making clear to them what they can
> or need to decide, giving them the info needed
> to do that.

Which we did here.

> > That's what Emacs does there.
> 
> I don't see it that way.  I don't understand
> the message, and it sounds like someone needs
> to know something about Emacs builds, its
> dependencies, and perhaps native compilation.

That's okay.  Some warnings will invariably left not understood by
some of the users, especially if they (users) lack background
knowledge about what happens in that case.  The usual remedy is to
ask.

> > That's an unfair comparison.  The warning in question did tell you
> > what was the problem: a specific program was missing or could not be
> > found.
> 
> What's the meaning/consequence of that program
> being missing?

If you know that Emacs compiles Lisp to native code, you will
understand the meaning of the assembler program being absent.  If you
don't, you won't, and will have to ask or look around for answers.

> > >  x86_64-w64-mingw32-gcc-11.3.0: fatal error: cannot
> > >  execute 'as': CreateProcess: No such file or directory
> > >
> > > Is that a problem?  I'm warned about it, so I
> > > guess maybe it is.  Is it a problem that I'm
> > > expected, and that I can, do something about?
> > > If so, what needs to be done?
> > 
> > What needs to be done is find out why GCC could not fine 'as', and fix
> > that.
> 
> The warning doesn't tell users that they need to
> do that, and _how_ to do it.

It can't.  There are gazillion reasons for the problem, each one with
a different solution.  One can write a small paper mentioning and
explaining them all.  It's impractical to expect Emacs to do that in a
warning.  What Emacs does here is point out that a certain required
program is missing.  It should be good enough to understand the
problem, like it is good enough when Emacs says some file is missing.

Or take this message as an example:

  Autoloading failed to define function SUCH-AND-SUCH

Users who don't know what autoloading is or does will be unable to
understand it or know how to fix it.  Like in this case.

> > > And your response is that this is all OK
> > > and expected?
> > 
> > No.  My response was quite more than that.
> 
> I'd say that the warning isn't very helpful
> to many/most users who would encounter it -
> unless it's never supposed to be seen and it
> results from a faulty Emacs build and is not
> really a user problem.
> 
> For most users to understand and act on the
> problem, I think the info communicated would
> need to be much better.

You are entitled to your views, but I don't share them.  And I don't
agree with your estimation of how many users won't understand what the
warning says.

(I also don't understand why we are still arguing when Corwin already
explained why the problem happened, and already uploaded a fixed
distribution.)