unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Andrea Corallo <akrl@sdf.org>
Cc: emacs-devel@gnu.org
Subject: Re: Updating *.el files and native compilation
Date: Mon, 10 May 2021 16:34:43 +0300	[thread overview]
Message-ID: <837dk67lvw.fsf@gnu.org> (raw)
In-Reply-To: <xjfmtt3rqg6.fsf@sdf.org> (message from Andrea Corallo on Mon, 10 May 2021 07:35:53 +0000)

> From: Andrea Corallo <akrl@sdf.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 10 May 2021 07:35:53 +0000
> 
> >   . if, for some reason, Emacs loads an incompatible .eln file, then
> >     some Lisp programs could crash the Emacs session, is that correct?
> >     If so, how do we make sure such incompatible changes always cause
> >     a new native compilation that yields a different file name for the
> >     .eln file?
> 
> Yes but this should not happen, every change that can introduce an
> incompatibility has to be accounted in the `comp-abi-hash' computation
> and AFAIK ATM it is.

Some changes don't require updating comp-abi-hash, but still create
*.eln files with different hashes in its name.  AFAIU, that happens
when the primitives don't change, but the .el file itself changes,
isn't that so?

In any case, are you saying that the only situations where loading and
using a .eln file could crash Emacs are those which are handled by
changing comp-abi-hash?  If so, how can we make sure we never fail to
update comp-abi-hash when that is needed?

> > The upshot of all this is that if one keeps multiple Emacs
> > executables, it should be safe to invoke each one of them without
> > risking crashes due to loading incompatible *.eln files that were
> > produced by other, subtly incompatible Emacs executables.  Is this
> > indeed safe, or do we have some "gotchas" that still need to be taken
> > care of?
> 
> As of today I'm not aware of any gotcha here, if we discover a case of
> this we should treat it as bug.

Sure.



  reply	other threads:[~2021-05-10 13:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-08  7:51 Updating *.el files and native compilation Eli Zaretskii
2021-05-10  7:35 ` Andrea Corallo via Emacs development discussions.
2021-05-10 13:34   ` Eli Zaretskii [this message]
2021-05-10 15:44     ` Andrea Corallo via Emacs development discussions.
2021-05-10 16:59       ` Eli Zaretskii
2021-05-10 20:45         ` Andrea Corallo via Emacs development discussions.
2021-05-11  2:27           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=837dk67lvw.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=akrl@sdf.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).