delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1999/06/15/18:03:06

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 <khan AT xraylith DOT wisc DOT EDU>
Reply-To: Mumit Khan <khan AT xraylith DOT wisc DOT EDU>
To: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: odd 'configure' problems
In-Reply-To: <199906152140.RAA04701@jaj.com>
Message-ID: <Pine.LNX.3.96.990615153814.10360Q-100000@mercury.xraylith.wisc.edu>
MIME-Version: 1.0

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019