Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com X-Authentication-Warning: mercury.xraylith.wisc.edu: khan owned process doing -bs Date: Tue, 15 Jun 1999 15:54:56 -0500 (CDT) From: Mumit Khan Reply-To: Mumit Khan To: cygwin AT sourceware DOT cygnus DOT com Subject: Re: odd 'configure' problems In-Reply-To: <199906152140.RAA04701@jaj.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 15 Jun 1999, Phil Edwards wrote: > I guess I should say that all the tools are Cygwin, with their required > cygwin1.dll, but the compiler produces -mno-cygwin stuff by default. A good way to think of this is in terms of cross-compiling -- whenever you specify -mno-cygwin, you're cross-compiling from Cygwin host to Mingw target. Cross-compilation unfortunately has some pitfalls which you have to look out for. > Done. I don't know where caddr_t is supposed to be typedef'd, but > my guess would be sys/types.h. I'll assume that I'm getting the > "wrong" sys/types.h for now. There *is* no caddr_t in neither ANSI nor POSIX. It's something that lots of the Unix headers define, but it doesn't have to be there. Hey, just be happy that you're getting the right result in this case, even if for the wrong reasons ;-) > configure:1337: checking for working mmap > configure:1485: gcc -o conftest -g -O2 conftest.c 1>&5 > In file included from configure:1370: > D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91. > 66/../../../../i586-cygwin32/include/sys/mman.h:31: parse error before `mmap' > D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91. > 66/../../../../i586-cygwin32/include/sys/mman.h:31: parse error before `__addr' > D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91. > 66/../../../../i586-cygwin32/include/sys/mman.h:31: warning: data definition has no type or storage class Here's your problem right there! Cygwin hsa sys/mman.h, but Mingw doesn't. Cygwin compiler in -mno-cygwin mode first searches the Mingw headers, and then continues on with the default headers, which happens to be Cygwin specific. In this case, it finds the it finds sys/mman.h, which has nothing to do with Cygwin and complains. It all has to do with -mno-cygwin mode, which is not as well tested or used, and that's why folks continue to get "surprised" at the weird little problems like this. I use a cross compiler on Unix to build Mingw binaries, and never have to deal with this "damn! accidentally picked up the wrong includes again" problem. One solution is to create a "real" cross-compiler from Cygwin to Mingw and then use that instead. The same instructions that I've posted on creating x-compilers will apply there as well. Disk space is much much cheaper than time and headache. Considering the number of messages I've responded to over the past year or so (lots sent directly to me), I'm beginning to consider -mno-cygwin evil ... Regards, Mumit -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com