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

[Andrea Corallo]

Andrea Corallo <akrl@sdf.org> writes:

[...]

> 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

I tried a fresh bootstrap of emacs-28 now and it is working for me.  I
guess what we are observing here is something related to some state of
the build?  Is it possible that your Emacs dumped two times?  See my
following notes:

Reading the source code I might have done some progress on the
investigation.  I guess this is just related to bug#45103 (read native
Emacs not supporting so far redumps).

When we execute loadup.el we prepare the native compilation units for
dump fixing up their filenames.

Comment at loadup.el:463

  ;; Fix the compilation unit filename to have it working when                  
                                                                                
      
  ;; installed or if the source directory got moved.  This is set to be         
                                                                                
      
  ;; a pair in the form of:                                                     
                                                                                
      
  ;;     (rel-filename-from-install-bin . rel-filename-from-local-bin).

Once dump is done reviving it at pdumper.c:5301 we expect to find a cons
as compilation unit filename.  If before dumping we do not prepare that
this will not happen so I don't think it can work.

I'm preparing a patch to add a check (I think is very healthy anyway) and
testing that my theory make sense, will follow up very soon.

  Andrea