>From a recent ./configure that I ran to install xfmail, I was told rather
rudely (IMHO) that I needed a functional mmap() in order to run the
program correctly.

Do we not have a working mmap()?

Here's a relevant discussion from the ./configure script:

----------------[begin clip]-------------------
/* Modified mmap test -- only tests if MAP_PRIVATE works */
/* Thanks to Mike Haertel and Jim Avera for this test.
   Here is a matrix of mmap possibilities:
        mmap private not fixed
        mmap private fixed at somewhere currently unmapped
        mmap private fixed at somewhere already mapped
        mmap shared not fixed
        mmap shared fixed at somewhere currently unmapped
        mmap shared fixed at somewhere already mapped
   For private mappings, we should verify that changes cannot be read()
   back from the file, nor mmap's back from the file at a different
   address.  (There have been systems where private was not correctly
   implemented like the infamous i386 svr4.0, and systems where the
   VM page cache was not coherent with the filesystem buffer cache
   like early versions of FreeBSD and possibly contemporary NetBSD.)
   For shared mappings, we should conversely verify that changes get
   propogated back to all the places they're supposed to be.

--------[end clip]--------------------

My assumption in the matter since I seem to recal a discussion of this in
previous postings is that the uvm memory model makes an attempt to fix
this sort of thing.. is UVM stable enough for me to be upgrading to
current? I'm running the latest NetBSD 1.3 release, as far as I can tell,
and it sure would be nice if I could just ignore this mmap() warning and
complete the compilation process.

Well thanks for any help you may be able to provide.. I've done a quick
search through certain archives, but mmap keywords avail me little useful
information.

Thanks,

Marc Tooley
tooleym@douglas.bc.ca