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

Previous Next

Package: emacs;

Reported by: Bartosz Bubak <bartosz.bubak <at> gmail.com>

Date: Wed, 5 Oct 2022 20:34:03 UTC

Severity: normal

Found in version 28.2

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: larsi <at> gnus.org, corwin <at> bru.st, 58318 <at> debbugs.gnu.org, bartosz.bubak <at> gmail.com
Subject: bug#58318: 28.2; Emacs installed from package won't work with MinGW
Date: Fri, 07 Oct 2022 16:48:16 +0300
> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: larsi <at> gnus.org, corwin <at> bru.st, bartosz.bubak <at> gmail.com,
>         58318 <at> 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?

> Indeed the other option is to precompile all trampoline AOT when we know
> libgccjit is available.  It is actually very simple with something like:
> 
> (mapatoms (λ (f)
>             (when (subr-primitive-p (symbol-function f))
>               (or (comp-trampoline-search f)
>                   (comp-trampoline-compile f)))))
> 
> It was not consired worth as trampoline production is very quick, but
> might be worth at least for Windows platforms for the discussed reason.

If calling through funcall is too expensive, I think pre-compiling all
the trampolines would indeed be the best solution, thanks.




This bug report was last modified 2 years and 253 days ago.

Previous Next


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