On Mon, Jul 25, 2022, 4:11 PM Andrea Corallo <akrl@sdf.org> wrote:

> Lynn Winebarger <owinebar@gmail.com> writes:
>
>
>
> While resurrecting from a dump an eln is mapped into memory if (at
> least) a native compiled function noted in the dump was loaded from it.
> So yeah the dumped state is preserved a no top level re-evaluation is
> happening.
>
> BTW I think so far we do not support re-dumping Emacs twice with native
> code.  This is not a deep technical limitaiton, it's only because how we
> fixup relative eln paths to support installed and non installed builds,
> we should probably work on this limitation...


I still can't figure out why building with native compilation and a
site-load file was producing an error about trying to load an incoherent
ELN file.
Now that I have a shell script for running make to compile the included
files during the evaluation of site-init, I'm going to attempt that build
again.
One thing I might do is expose the "all_loaded_comp_units_h" variable in
lisp, so I can check whether all the ELN files were actually loaded and
compare that list against the one computed in loadup based on identifying
native subrs bound to function symbols.  That would provide a sanity check
during the dump.  It might be better to just explicitly base the mapping on
that hash table directly just to ensure no loaded compilation units are
missed while dumping.

Lynn