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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 27 Oct 2021 19:32:30 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: kbrown@cornell.edu, emacs-devel@gnu.org
>> 
>> > Date: Sun, 17 Oct 2021 08:56:20 +0300
>> > From: Eli Zaretskii <eliz@gnu.org>
>> > Cc: kbrown@cornell.edu, emacs-devel@gnu.org
>> > 
>> > > From: Andrea Corallo <akrl@sdf.org>
>> > > Cc: kbrown@cornell.edu, emacs-devel@gnu.org
>> > > Date: Sat, 16 Oct 2021 20:15:09 +0000
>> > > 
>> > > > Now the subr--trampoline*.eln files are in the right place, but this
>> > > > problem:
>> > > >
>> > > >>   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
>> > > >
>> > > > still exists.  So something else is amiss here.
>> > > 
>> > > Okay, I'll have a look into this I guess Monday.
>> > 
>> > Thanks.
>> > 
>> > > > Btw, why are these subr--trampoline*.eln files get generated when
>> > > > building the tarball, but not when building from Git "normally", where
>> > > > the *.eln files are produced by batch-byte+native-compile?  Because I
>> > > > don't see any such files that correspond to the build from Git
>> > > > anywhere on my system.
>> > > 
>> > > The obvious answer is that something is either redefining or advising
>> > > those primitives.  If it's important to know what and where we can
>> > > investigate it, it should not be extremely difficult.
>> > 
>> > I'm curious why 2 methods of native compilation that are supposed to
>> > produce identical results, in reality produce slightly different
>> > results: one produces these trampoline files, the other doesn't.  It
>> > could be that there's some hidden issue here, perhaps even related to
>> > those errors at startup described above.
>> 
>> Andrea, any progress in investigating this strange problem?  It is
>> currently the only hard blocking issue that prevents us from making a
>> pretest tarball.

Hi Eli,

I must apologize, I've also completely missed your previous mail.

I'm behind schedule as I'm in a late with some GCC work where I'm trying
to meet the stage1 deadline.  As a result haven't progressed much on
this investigation.

> I now have the same problem in the "normal" build with native-comp of
> the release branch, the one that builds from Git clone and uses
> ELC+ELN to compile all the preloaded files (as opposed to building a
> release tarball).  The problem shows at startup:
>
>   $ emacs -Q -nw
>
> 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.

  Andrea