emacs-devel
[Top][All Lists]
Advanced

[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: Sun, 02 Oct 2022 20:44:39 +0300

> From: Rob Browning <rlb@defaultvalue.org>
> Cc: david@tethera.net, emacs-devel@gnu.org, akrl@sdf.org
> Date: Sun, 02 Oct 2022 12:37:33 -0500
> 
> We've also for a long time made the emacs-el package (containing all the
> .el files) optional for similar reasons (constrained environments), but
> we recently had to start requiring it because (not sure why yet) emacs
> just crashes in some situations when the .el files aren't available and
> when native compilation is enabled.

Loading of natively-compiled files cannot work if the source files
aren't accessible, because loading a .eln file involves verifying that
it was produced from that particular .el file.  (The .el file can be
compressed if Emacs was compiled with zlib support.)

But Emacs should not "crash" if the *.el files aren't available, it
should simply refuse to load any *.eln files and load the *.elc files
instead.  That produces many warnings, of course, but I hope your
users don't consider that "crashing".

> If it hasn't already been fixed in 28.2 (haven't tested yet), it'd be
> nice if we could eventually track that down and then switch emacs-el
> back to optional (back to "suggested" in Debian dependency parlance).

It isn't a bug, but intended behavior.  If we want to remove this
dependency, some non-trivial ideas about reworking the current load
procedure should emerge.  I don't thin we have any such ideas at this
time.



reply via email to

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