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

[Eli Zaretskii <eliz@gnu.org>]

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

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