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


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

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: Re: bug#58318: 28.2; Emacs installed from package won't work with
 MinGW
Date: Fri, 07 Oct 2022 15:54:25 +0300
> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, corwin <at> bru.st, bartosz.bubak <at> gmail.com,
>         58318 <at> debbugs.gnu.org
> Date: Fri, 07 Oct 2022 12:35:52 +0000
> 
> >> > 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.

I didn't mean gcc, I meant cc1.  But maybe libgccjit can play its
role, I don't know.

> > 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.

What about other primitives? fset can be used for more than just this
one.

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

How is this relevant only to Windows?

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.




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.