Re: Objects that can't be purified during dumping

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

On Sun, Jul 24, 2022, 11:07 AM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > changing the c source would require re-native-compiling all the elisp
> files
> > I'm including in the dump,
>
> I thought that was not supposed to be the case (the re-compiling should
> only be needed for *some* changes, tho I'm not exactly clear on what
> those are).


The hash is computed from the "major abi version" constant in the source,
the platform string, the list of subrs installed after the last
"symbols_of" procedure is called in main and (drum roll...) the options to
the configure script, with some modifications.  I haven't found where that
last step is done, so I'm not sure exactly how those are massaged, but at
least the -O and -g flags to gcc appear to be set to -O1 regardless of the
actual flags, so you can debug .elns produced by an optimized emacs.  It
would be nice if the build system facilitated making these multiple
versions, though.
On the other hand, if you do something like copy a configure command like
"../configure --without-native-compilation <other flags>" from the config
log of one build directory to configure in a second build directory, and
just add an option on the end:
""../configure --without-native-compilation <other flags>
--with-native-compilation"
Do your while build, etc, then decide to rebuild with -O0 -g3, but notice
how stupid having contradictory flags looks, so you rebuild using:
"../configure  <other flags>  --with-native-compilation",
Then the hash will be different and you won't be able to load the ELN files
compiled with the first build.
So, there could be some more normalization of the configure options, but
the current approach seems conservative.
I don't know if there is any implicit assumption that the compile is done
by an Emacs with only "loadup" in the dump.  I do know that when I ran the
build using a dump file containing all those additional core libraries,
something had made call-interactively advise itself (directly or
indirectly), so I was getting massive numbers of processes compiling
call_interactively_0 subrs.  So the subrs in the dump might be relevant to
the usability of the resulting ELN file, even though the compile is
otherwise done in a "clean" compile time environment.

Lynn


Lynn

[-- Attachment #2: Type: text/html, Size: 3138 bytes --]