[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suppressing native compilation (short and long term)

From: Eli Zaretskii
Subject: Re: Suppressing native compilation (short and long term)
Date: Sat, 05 Nov 2022 15:35:29 +0200

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 5 Nov 2022 14:12:03 +0100
> Cc: larsi@gnus.org, akrl@sdf.org, rlb@defaultvalue.org, 
>       monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org
> > I see no reason to change what -Q means, even though some people, for
> > reasons I cannot grasp, consider JIT native compilation to be
> > "unusual".
> I don't consider it unusual, except that in my build, if I enter Emacs, load 
> something
> that triggers native compilation, and exit quickly, the subprocesses crash (I 
> get
> invitations to "connect with gdb and debug them", which disappear after a few 
> seconds).

They aren't supposed to crash, and they didn't in Emacs 28.  So this
should be reported with enough detail for us to be able to fix the
crashes.  This could be related to bug#58956, btw.

> > Suppose you start "emacs -Q" where some of the *.el files were already
> > compiled into the corresponding *.eln files, would you then expect
> > "emacs -Q" not to use those *.eln files, and instead to load the *.elc
> > files?  If yes, why?  If not, how does this differ from when you
> > invoke "emacs -Q" and the *.eln files do not yet exist, but are
> > produced when Emacs loads the corresponding package?
> Loading them and using them wouldn't be a problem, because it does *not* 
> write anywhere,
> while producing them does. In my case, they do just where I don't want them 
> to be.

But we have features who write even under "emacs -Q", don't we?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]