bug#41242: Port feature/native-comp to Windows

[Andrea Corallo <akrl@sdf.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org
>> Date: Sat, 23 May 2020 10:37:18 +0000
>>
>> >> https://akrl.sdf.org/gccemacs.html#orgb063106
>> >
>> > Thanks.  I guess this changes a lot in how Emacs starts up?  E.g.,
>> > what happens if the .el file was in the meantime modified and
>> > recompiled into the .eln file? we will load the new versions instead
>> > of the one that was preloaded, right?
>>
>> This is something we have to define.  Currently we only complain if one
>> of the defined functions that was dumped cannot be found in the new
>> .eln.  My preference would be to sign each .eln used for dump to make
>> sure what we are loading is what we dumped and refuse to load otherwise.
>>
>> BTW reloading from dump the "dumped" eln are not located by searching in
>> the load-path for all suffix.  The eln position is stored into the
>> compilation unit object for performance reasons.
>
> Are you saying we store the absolute file name of the .eln files in
> the pdumper file?  If so, how can Emacs start up if the .eln files
> were moved to another location, e.g. as part of "make install", or
> more generally if Emacs was relocated since it was dumped?

To be precise we store the relative path of the .eln from the emacs
executable, both for the local build both for the file position we will
have after a "make install".

Reloading the first compilation unit the code detect in which of this
two cases we are (this is where file-exists is called) and this
information is used for all the following compilaiton unit to be
revived.

>> The performance problem Nicolas is discussing is related to the non
>> dumped .elns loaded at startup I believe.
>
> This is not about the performance issue, this is about the crash
> because emacs_dir was not yet defined where Emacs needed it: a
> different issue uncovered by Nicolas.

Ops got confused between the two branches of this same thread.

--
akrl@sdf.org