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

[Andrea Corallo]

Andrea Corallo <akrl@sdf.org> writes:

> 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.

Okay that's not the issue as I guess while preparing the release binary
we don't redump native code.  I've pushed 9d6162053e to add the sanity
check anyway as I think it's still good to check everything is coherent
there.

  Andrea