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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Nicolas Bértolo <nicolasbertolo@gmail.com>,
>>         41242@debbugs.gnu.org
>> Date: Sat, 23 May 2020 08:35:43 +0000
>> 
>> >> When loading a dump file that contains native compiled elisp we try to 
>> >> find the
>> >> .eln file. This uses Ffile_exists_p(). This function, in turn, calls
>> >> Fexpand_file_name(). This function will use the root directory as
>> >> `default_directory' as a fallback.
>> >> 
>> >> Getting the root directory requires reading the $emacs_dir environment 
>> >> variable.
>> >> This is setup later in the initialization process. This caused a crash.
>> >
>> > Can you tell why this doesn't happen when *.elc files are used
>> > instead?  Also, what do you mean by "loading a dump file that contains
>> > native compiled elisp"? how did native compiled ELisp get into the
>> > dump file in the first place?
>> 
>> Hi Eli,
>> 
>> you may be interested in this paragraph
>> 
>> 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.  The performance
problem Nicolas is discussing is related to the non dumped .elns loaded
at startup I believe.

  Andrea

-- 
akrl@sdf.org