GNU bug report logs - #58318
28.2; Emacs installed from package won't work with MinGW

Previous Next

Full log

Message #38 received at 58318 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, corwin <at> bru.st, 58318 <at> debbugs.gnu.org,
 bartosz.bubak <at> gmail.com
Subject: Re: bug#58318: 28.2; Emacs installed from package won't work with
 MinGW
Date: Fri, 07 Oct 2022 12:35:52 +0000

[Message part 1 (text/plain, inline)]

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

>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Cc: Andrea Corallo <akrl <at> sdf.org>,  corwin <at> bru.st,  bartosz.bubak <at> gmail.com,
>>   58318 <at> debbugs.gnu.org
>> Date: Fri, 07 Oct 2022 14:04:57 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Maybe there's a misunderstanding of what you meant by "if a compiler
>> > isn't present".  By "the compiler" do you mean libgccjit, or is it GCC
>> > and Binutils (or maybe all 3 together)?  IOW, are you talking about
>> > the ability to load existing *.eln files, or are you talking about the
>> > ability to both load existing *.eln files and produce new ones?
>> 
>> I'm talking about trampolines, nothing else.
>
> Trampoline generation requires all the 3 components to be present,
> AFAIK.  Andrea, am I right?

AFAIU only libgccjit and Binutils are necessary, but libgccjit *is* GCC
(in the sense another frontend fo the GNU Compiler Collection).  I
*think* gcc the binary (read the C frontend) should not be required.
But I don't know how distros package libgccjit and gcc, there might be
some dendency I'm not aware of.

>> > The startup code currently detects that libgccjit is unavailable or
>> > cannot be loaded, and if so, disables all the aspects of
>> > native-compilation: both JIT compilation of *.el and production of the
>> > trampolines.  I'm not aware that when we disable those two, we get
>> > Emacs that is not "fully functional".
>> 
>> If native compilation is disabled in a native-compiled Emacs, then 
>> 
>> (fset 'yes-or-no-p 'y-or-n-p)
>> 
>> doesn't work (for calls to `yes-or-no-p' in native-compiled code).
>> That's what I meant by "not fully functional".
>
> If it indeed doesn't work (and I wasn't aware it didn't work), we
> should try fixing it, if that is feasible.

Yes because `yes-or-no-p' is a primitive, so with no trampolines its
redefinition is not functional.

A quick ad-hoc fix for `yes-or-no-p' is attached.  It does not have a
perf impact as `yes-or-no-p' will have to wait for the user input
anyway, if okay I can push it.

Oherwise another strategy would be to disable direct calls from lisp
native code into primitives on Windows, this indeed has a performance
impact.

[0001-Add-yes-or-no-p-to-native-comp-never-optimize-functi.patch (text/x-diff, inline)]

From a6d736d532e20b6763a7ff1995f952fc293886dd Mon Sep 17 00:00:00 2001
From: Andrea Corallo <akrl <at> sdf.org>
Date: Fri, 7 Oct 2022 12:28:51 +0000
Subject: [PATCH] * Add `yes-or-no-p' to
 `native-comp-never-optimize-functions'.

* lisp/emacs-lisp/comp.el (native-comp-never-optimize-functions): Add
`yes-or-no-p'.
---
 lisp/emacs-lisp/comp.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
index 5ee10fcbca2..2812e53bcc2 100644
--- a/lisp/emacs-lisp/comp.el
+++ b/lisp/emacs-lisp/comp.el
@@ -104,7 +104,7 @@ native-comp-never-optimize-functions
   '(;; The following two are mandatory for Emacs to be working
     ;; correctly (see comment in `advice--add-function'). DO NOT
     ;; REMOVE.
-    macroexpand rename-buffer)
+    macroexpand rename-buffer yes-or-no-p)
   "Primitive functions to exclude from trampoline optimization."
   :type '(repeat symbol)
   :version "28.1")
-- 
2.35.1.577.g74cc1aa55f

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.