begin Steve Lord quotation:
> On Fri, 2002-01-04 at 12:39, Sean Neakums wrote:
>> I think I can finally reproduce the bogus dumps. I just did it here,
>> three times. What I did was: run the io-test program above on two
>> different files for approx three minutes, then start the emacs dump.
>> When the dump completed, I started a third io-test and left the three
>> of them run for about five or so more minutes. What I'm trying to do
>> with all this I/O is to force the dumped binary's pages to be written
>> to disk.
> Can you expand on the 'dumps' I am not really familiar with the
> emacs build process, so I don't know which part of the process
> you are refering to here.
Of course, my bad. An Emacs binary contains a bunch of C code making
up the Lisp interpeter and primitive functions (subrs) and a .data
section that contains pre-loaded Lisp code. I think they get the Lisp
code into the .data section by allocating a large array and using it
as Lisp storage. The idea is for the code that is used to implement
basic editor functionality to be present as soon as the binary is
execed. It's handled by copying out the constituents of the binary
from core to a fresh file. On Linux, this is handled by the code in
src/unexelf.c. The comments seems to describe the process fairly
thoroughly; much of the detail is beyond me.
If you have a tree in which you've already built Emacs, doing a dump
is very straighforward:
$ cd src
$ LC_ALL=C ./temacs -batch -l loadup dump
You'll get a bunch of messages about Lisp files being loaded, and then
it will tell you to which files it has dumped the emacs.
///////////////// | | The spark of a pin
<sneakums@xxxxxxxx> | (require 'gnu) | dropping, falling feather-like.
\\\\\\\\\\\\\\\\\ | | There is too much noise.