Re: Building a release tarball generates trampoline files in eln-cache

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Andrea Corallo <akrl@sdf.org>,  emacs-devel@gnu.org
> Date: Tue, 02 Nov 2021 16:26:22 -0400
> 
> Eli Zaretskii [2021-11-02 21:47:42] wrote:
> >> From: Andrea Corallo <akrl@sdf.org>
> >> Cc: emacs-devel@gnu.org
> >> Date: Tue, 02 Nov 2021 19:22:56 +0000
> >> > This shows errors in the *Compile Log* buffer(??)
> >> >
> >> >   lisp/emacs-lisp/seq.elc: Error: Symbol’s function definition is void: gv-setter
> >> >   lisp/term/xterm.elc: Error: Symbol’s function definition is void: t
> >> >
> >> > If I delete seq.elc, the problem goes away.
> >> >
> >> > How do I investigate this?
> >> 
> >> I guess a start is to run in gdb to see where the function definition of
> >> gv-setter was last time changed (if ever).
> >> 
> >> I guess `gv-setter' was compiled and dumped, therefore its definition
> >> it's expected to be revived by 'load_comp_unit' called from
> >> pdumper.c:5355 while Emacs is starting-up.
> >
> > Thanks, will try.
> >
> > Any idea why the errors show in *Compile Log* buffer?  Where did that
> > buffer come from?
> 
> I'd guess that it's when `cl-generic.el` calls `byte-compile` (both
> seq.el and xterm.el use `cl-defmethod`).
> `cl-generic.el` is also one of the rare users of `gv-setter`.
> OTOH, `gv-setter` normally doesn't appear within the code that
> `cl-generic.el` passes to `byte-compile`, instead `gv-setter` is called
> directly by `cl-generic.el`, so my guess might be off.

Maybe, maybe not.

The crucial detail here is that I invoke "emacs -nw" (are you using
"-nw" in your attempts to reproduce?).  What happens then is that we
load the terminal-specific support file, in this case xterm.elc,
during startup.  And since xterm.el is not preloaded, it is not
natively-compiled by the build process.  So once we load it, Emacs
tries to native-compile it, and all of its prerequisites, and that's
where those errors and that compile log buffer come from, I guess.

I tried to mark xterm.el and seq.el as not for native-compile, but
that didn't help.  However, if I manually compile gv.el natively into
a *.eln file, the problem goes away.

So why would Emacs want to native-compile gv.el in this case, and why
trying that causes this problem?  Maybe we should add gv.el to the
list of files that are natively-compiled as part of the build?

Interestingly, if gv-XXX.eln is available, Emacs still loads bytecomp
at startup, but I don't see any evidence that it compiles xterm.el
natively: no subprocesses and no xterm-XXX.eln files are created.  Why
does it load bytecomp, and what prevents it from natively compiling
xterm.el in this case?