[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#58318: 28.2; Emacs installed from package won't work with MinGW
From: |
Andrea Corallo |
Subject: |
bug#58318: 28.2; Emacs installed from package won't work with MinGW |
Date: |
Fri, 07 Oct 2022 12:35:52 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: Andrea Corallo <akrl@sdf.org>, corwin@bru.st, bartosz.bubak@gmail.com,
>> 58318@debbugs.gnu.org
>> Date: Fri, 07 Oct 2022 14:04:57 +0200
>>
>> Eli Zaretskii <eliz@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.
>From a6d736d532e20b6763a7ff1995f952fc293886dd Mon Sep 17 00:00:00 2001
From: Andrea Corallo <akrl@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
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Bartosz Bubak, 2022/10/05
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/06
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Corwin Brust, 2022/10/06
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Lars Ingebrigtsen, 2022/10/06
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/06
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Lars Ingebrigtsen, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Lars Ingebrigtsen, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Lars Ingebrigtsen, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW,
Andrea Corallo <=
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Lars Ingebrigtsen, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Lars Ingebrigtsen, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Lars Ingebrigtsen, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Andrea Corallo, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Andrea Corallo, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Eli Zaretskii, 2022/10/07
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, Andrea Corallo, 2022/10/07