Lars Gullik Bjønnes wrote: >"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: > >| On Thu, Dec 06, 2001 at 08:39:47AM +0100, Lars Gullik Bjønnes wrote: > >>>Ben Stanley <[EMAIL PROTECTED]> writes: >>> >>>| Please let me know if the attached patch fixes this problem. >>> >>>| I also tried to fix the Solaris compile problem - Kayvan, could you >>>| please test it? >>> >>>I am pretty sure that this is not how we are going to solve this >>>problem. >>> >| I don't like adding the POSIX level hack either. > Hmmm... I think that this is the right approach, but what I sent in was a hack. See below.
> >| How about this? (it compiles for me on Solaris). > >No, won't do. > No, I don't like that either. That won't compile elsewhere. >Either disable mmap for those platforms of find a better solution. > Hmmm... let's try for the better solution. It seems that we have 2 distinct problems: 1) Solaris headers by default provide an old version of munmap with the wrong type in there. 2) compaq provides a definition of MAP_FAILED with a similarly wrong type. The Solaris headers can be told to give us a POSIX compliant definition of munmap by doing #define _POSIX_C_SOURCE 199506L before #include <sys/mman.h> This seems to be fairly standard - see http://vicente.org/xclib/include/xc/standards.h.html http://www.cs.arizona.edu/computer.help/policy/DIGITAL_unix/AA-QTLMA-TE_html/relnotes5.html Also mentioned at http://mail.gnu.org/pipermail/autoconf/2000-August/006020.html, but this suggests problems with defining this unconditionally on Solaris... This solution would mean that we only have to support POSIX mmap, instead of several non-standard variants. This removes #ifdef and reinterpret_cast clutter from the code, which I consider to be a great advantage. It would be nice to have access to some man pages for the platforms in question. The compaq headers may have a similar feature. The definition that Jean-Marc looked up is also a compatibility defintion. The compq man page suggested looking at standards(5) - Jean-Marc, could you please take a look at this, and perhaps send it to me? Specifically, does it mention _POSIX_C_SOURCE? So, I think that the _POSIX_C_SOURCE define may fix both problems, but I would like to see authorative documentation. I think it is probably safe to define this macro unconditionally for this file because we only need mmap here, and on Linux it has no effect. Ben.