Read the manual.

It is invalid

invalid

ok, care to mention where I can find the text about it? 
 
what I did was:  
 
grep -rl xemacs.dmp / 
 
which gives no hits.  
 
also, I checked the debian distribution, they don't have such a file either. 
what is it good for and why does it have to be packaged as non-executable 
inside bindir?  

There is thew configure option --enable-pdump and there is
a not used configure option --enable-dump-in-exec.

Beside this Fabian will include an automagic test if the
binary needs the dump or if it do not need this.  This
may depend on the architecture and other configure options.

Yes, as Werner says, it depends on the configure options.
The XEmacs which is currently in STABLE is build with
the configure options "--disable-mc-alloc" "--disable-kkcc":

    - use configure options "--disable-mc-alloc" "--disable-kkcc"
      for now, when using the new allocation scheme and the new
      garbage collector, I cannot build XEmacs anymore on x86_64.

But that x86_64 build problem has been fixed in the mean time
and I will enable mc-malloc and kkcc again.

That means that the .dmp file will again become necessary,
unless I explicitely give the option --enable-dump-in-exec:

  --enable-pdump          Enable portable LISP preloader.
  --enable-dump-in-exec   Enable dumping into executable (enabled by default
                          for `pdump', not enabled by default in combination
                          with `mc-alloc').

I'm not sure whether I should add this option, maybe it is not enabled
when using mc-alloc for a reason.

As Werner suggested, I will check the output of configure,
which contains something like this:

    [...]
    Other Features:
      Inhibiting IPv6 canonicalization at startup.
      Compiling in support for dynamic shared object modules.
      Using the new portable dumper.
      Dumping into executable.
    [...]

If "Dumping into executable" is there, I will not install the .dmp
files, if not I will install them.

Probably they will be necessary again with the next update because of
mc-alloc. I'll ask upstream why dumping into the executable is
disabled when using mc-alloc.

reopening against mfabian  

try 2 

Apparently it is not a good idea to dump into the executable when
using 'mc-alloc'. I asked on the xemacs-beta mailing list and
got the following response:

From: Marcus Crestani <crestani@informatik.uni-tuebingen.de>
Subject: Re: can --enable-dump-in-exec be used with 'mc-alloc'?
To: mfabian@suse.de
Cc: xemacs-beta@xemacs.org
Date: Mon, 01 Aug 2005 21:52:38 +0200
Gnus-Warning: This is a duplicate of message <878xzlqvsp.fsf@informatik.uni-tuebingen.de>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.5-b21 (corn, linux)
Content-Type: text/plain; charset=us-ascii

>>>>>"MF" == Mike FABIAN <mfabian@suse.de> writes:
MF> Is there a specific reason why is it not enabled by default when
MF> using 'mc-alloc'?

With `mc-alloc', the dumped data is not used directly out of the dump
file; each dumped object is handed to the allocator.  Therefore, the
dump image has only to be present in memory while restoring the dumped
objects, which is done immediately after XEmacs is launched.  After
that, the memory of the dump image can be freed.

If the dump image is written into the executable, this memory cannot
be freed, and thus the dumped objects are using twice their size in
memory (in the dump image and allocated with the new allocator).

If the dump image is written into a separate file, this memory can be
freed after loading the objects.  The size of the dump image depends
on your configuration and is approximately 5 MB.

With this configuration option, the user has the choice: separate file
vs. memory wastage.

MF> Is that default meant as a recommendation not to enable it when
MF> using 'mc-alloc'?

Yes, assuming the user wants to save memory.

-- 
Marcus

xemacs updated to 21.5.21.20050721 submitted to STABLE.  Fixes several
crashes on 64 bit systems.  xemacs-*.dmp file is used again because
the new allocator ('mc-alloc') is enabled now.

→ FIXED.