Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Date:	Thu, 15 Apr 2004 11:40:50 +0200
From:	"Gerrit P. Haase" <freeweb AT nyckelpiga DOT de>
Reply-To:	"Gerrit P. Haase" <freeweb AT nyckelpiga DOT de>
Organization:	Esse keine toten Tiere
Message-ID:	<114843710892.20040415114050@familiehaase.de>
To:	"Dave Korn" <dk AT artimi DOT com>
CC:	cygwin AT cygwin DOT com, Eric Hanchrow <offby1 AT blarg DOT net>,
	Volker Quetschke <quetschke AT scytek DOT de>
Subject:	Re: gcc -mno-cygwin finds the wrong include files
In-Reply-To:	<NUTMEGbzhtDixykQYeC00000444@NUTMEG.CAM.ARTIMI.COM>
References:	<NUTMEGbzhtDixykQYeC00000444 AT NUTMEG DOT CAM DOT ARTIMI DOT COM>
MIME-Version:	1.0

Hi Volker, Dave,

I see the same problem as Volker.  Interesting issue that Eric doesn't
see it. 


> --------snip--------
> ignoring nonexistent directory "/usr/local/include/mingw"
> ignoring duplicate directory "/usr/include/mingw"
> ignoring duplicate directory
> "/usr/i686-pc-mingw32/lib/../../include/w32api"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/include
> --------snip--------

>   HEY!  WTF is that doing there?  THAT DOES NOT BELONG!

> --------snip--------
>  /usr/i686-pc-mingw32/include
>  /usr/include/w32api
> End of search list.
> --------snip--------

>   I noticed this rather peculiar entry in the specs file:

> --------snip--------
> *mingw_include_path:
> i686-pc-cygwin
> --------snip--------

> which looks wrong, but doesn't seem to be used anywhere.  However, I think
> the underlying cause is that cc1.exe most likely contains a hard-coded path
> to the target-dependent include dir, and since there's only one actual .exe
> serving as *both* target dependent compilers, there's one path there.

>   It might be possible to fix this by adding a -idirbefore option in the
> specs file, dependent on the -mno-cygwin switch, to add the correct
> i686-pc-mingw32/3.3.1/include directory earlier than the cygwin one.  Other
> fixes would work also.


Dave, thanks for the analysis, I want to release a new version as soon
as I have some spare time.  I'll try to verify that this is fixed with
the update.

BTW, in case of stddef.h and other std headers it would not hurt much
because the files are identical for Cygwin and MinGW, the only
difference between these two directories is actually this in the gcj
subdiretory: 

diff -urdN i686-pc-cygwin/3.3.1/include/gcj/libgcj-config.h i686-pc-mingw32/3.3.1/include/gcj/libgcj-config.h
--- i686-pc-cygwin/3.3.1/include/gcj/libgcj-config.h    2003-10-25 06:04:15.001000000 +0200
+++ i686-pc-mingw32/3.3.1/include/gcj/libgcj-config.h   2003-08-14 11:21:26.000000000 +0200
@@ -8,7 +8,7 @@
    included in user code.  */
 
 /* Define if hash synchronization is in use.  */
-/* #undef JV_HASH_SYNCHRONIZATION */
+#define JV_HASH_SYNCHRONIZATION 1
 
 /* Define if <inttypes.h> is available.  */
 #define JV_HAVE_INTTYPES_H 1



Gerrit
-- 
=^..^=                                     http://nyckelpiga.de/donate.html


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -