[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 13:54:05 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: larsi@gnus.org, corwin@bru.st, bartosz.bubak@gmail.com,
>> 58318@debbugs.gnu.org
>> Date: Fri, 07 Oct 2022 13:04:55 +0000
>>
>> > How is this relevant only to Windows?
>>
>> Windows is the only system where a native compiled Emacs can start even
>> if libgccjit is not present. On GNU/Linux we get and error at load time
>> from the dynamic linker in case. As a consequence on GNU/Linux Emacs is
>> always capable of producing trampolines when needed.
>
> It could be that libgccjit is loaded but is incompatible or
> something. So I'd prefer a general solution.
>
>> > And what do you mean by "disable direct calls from Lisp native code
>> > into primitives"? I don't think I understand what this would do in
>> > practice.
>>
>> Native compiled elisp calls directly into primitive functions not to go
>> through funcall. For this reason when a primitive is redefined we need
>> to produce a trampoline in order to forward these calls to the funcall
>> machinery. If we disable all of this optimization the issue disappears
>> but indeed that's not good from a performance point of view.
>
> How much will performance suffer if we use funcall?
This is the usual 1 milion dollar question, we can run benchmarks but we
are never sure of how much realistic they are. That said IME this is
one of the most effective optimizations we have, funcall is a non
trivial and relatively slow machine when executed at each function
activation.
Andrea
- bug#58318: 28.2; Emacs installed from package won't work with MinGW, (continued)
- 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, 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 <=
- 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, Corwin Brust, 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, Corwin Brust, 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