can't dump emacs-21.1 on redhat 7.1 nfs-mounted file system

[Dale Hagglund]

I'm trying to compile emacs-21.1 on my redhat 7.1 box at work.  The
uname -a information is

        $ uname -a
        Linux dernhelm 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown

I build outside the unpacked source tree, with the sequence

        $ ../emacs-21.1/configure --prefix=$HOME/pkg/emacs-21.1
        $ make

At the end of this process, I *apparently* have a dumped emacs
executable, src/emacs.  On closer inspection, however, things aren't
quite right.

        dernhelm$ ls -l src/emacs
        -rwxr-xr-x    2 rdh      yotta     6600450 Oct 28 15:06 src/emacs

        dernhelm$ file src/emacs
        src/emacs: ASCII text, with no line terminators

        dernhelm$ od src/emacs
        0000000 000000 000000 000000 000000 000000 000000 000000 000000
        *
        31133400 000000
        31133402

        dernhelm$ du -sk src/emacs
        16      src/emacs

So, the size and modes are right, but the file contains only zeroes,
and only 16kB of the apparent 6.6MB are allocated.

The file system I'm building on is nfs mounted from a freebsd file
server, so it's possible there's some bizarre nfs interaction going
on.  Also, I noticed that undump opening files with linux's large file
support enabled, so I though I'd try varying that as well.  I tried
the following three build cases:

        (a) nfs build directory, no configure options; 

        (b) nfs build directory, --disable-largefile; and

        (c) local build directory, no configure options.

Both (a) and (b) exhibit the same problem.  (c) creates a proper
dumped emacs.

I've investigated somewhat, and it appears that the undump process
uses the mmap system call on linux.  So, it appears there's either a
generic linux problem with mmap on nfs-mounted file systems, or some
sort of incompatibility between the linux nfs client and the freebsd
nfs server.

I did a bit of web searching, and in at least some corners of the
world, mixing mmap and nfs is not considered highly likely to work in
general.

Dale Hagglund.