[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Objects that can't be purified during dumping

From: Lynn Winebarger
Subject: Re: Objects that can't be purified during dumping
Date: Sun, 7 Aug 2022 07:27:02 -0400

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]