Re: Finalizing 'inhibit-automatic-native-compilation'

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Lynn Winebarger <owinebar@gmail.com>, monnier@iro.umontreal.ca,
>         emacs-devel@gnu.org
> Date: Mon, 06 Feb 2023 10:15:28 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Lynn Winebarger <owinebar@gmail.com>
> >> Date: Sat, 4 Feb 2023 17:05:19 -0500
> >> Cc: rms@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> >> 
> >> On Sat, Feb 4, 2023 at 3:08 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >> >
> >> > > Something in emacs is putting advice on call-interactively.  When I
> >> > > extended the baseline dump to include essentially all libraries
> >> > > included with emacs with native-compilation, it caused an infinite
> >> > > (asynchronous) regress while compiling the trampoline for
> >> > > call-interactively.  I wasn't aware of this until /tmp filled up.
> >> >
> >> > Is this with Emacs 28 or Emacs 29?
> >> 
> >> This was with 28.1 modified to support dumping with many pre-loaded
> >> native-compiled files.
> >
> > I asked because Emacs 29 adds some changes specifically intended to
> > solve the problem of infinite recursion in trampoline compilation.
> >
> >> As far as I know, emacs still doesn't support dumping arbitrary
> >> native-compiled libraries at compile-time.
> >
> > What problems do you see if you try?  AFAIR, if you tweak
> > native-comp-eln-load-path so that the *.eln files you want to dump are
> > directed to the ../native-lisp directory relative to where the Emacs
> > binary lives, then dump Emacs, loading such a dumped Emacs should
> > work.
> >
> > Andrea, am I missing something?
> 
> I think he might be talking about re-dumping Emacs?

Yes.  I'm saying that for re-dumping one should make sure that the
additional dumped *.eln files are in the ../native-lisp directory
relative to where the Emacs binary lives, and then when Emacs is
restarted, it will find those *.eln files at startup time.