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
From:	"Dave Korn" <dk AT artimi DOT com>
To:	<cygwin AT cygwin DOT com>
Subject:	RE: gcc -mno-cygwin finds the wrong include files
Date:	Tue, 13 Apr 2004 19:08:17 +0100
MIME-Version:	1.0
In-Reply-To:	<87ptab7p0i.fsf@offby1.atm01.sea.blarg.net>
Message-ID:	<NUTMEGbzhtDixykQYeC00000444@NUTMEG.CAM.ARTIMI.COM>
X-OriginalArrivalTime:	13 Apr 2004 18:08:17.0171 (UTC) FILETIME=[4BA3D630:01C42182]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Eric Hanchrow
> Sent: 13 April 2004 18:43

>     > Hi,
>     > when I use the following command gcc finds the wrong include
>     > file.
>     > $ echo "#include <stddef.h>" | gcc -mno-cygwin -E -

>     Hi, could someone please confirm that this is a bug, and not a
>     problem that exists only on this computer.
> 
> I just tried it, and got reasonable-looking output:
> 
> # 1 "<stdin>"
> # 1 "<built-in>"
> # 1 "<command line>"
> # 1 "<stdin>"
> # 1 "/lib/gcc-lib/i686-pc-mingw32/3.3.1/include/stddef.h" 1 3 4

  I just tried it, and didn't:

--------snip--------
dk AT mace /davek> echo "#include <stddef.h>" | gcc -mno-cygwin -E -
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "<stdin>"
# 1 "/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/include/stddef.h" 1 3 4
--------snip--------

  Dude, that's like *sooooooo* wrong.  Let's check that search path.

--------snip--------
dk AT mace /davek> echo "#include <stddef.h>" | gcc -mno-cygwin -E -v -
Reading specs from /usr/lib/gcc-lib/i686-pc-mingw32/3.3.1/specs
--------snip--------

  So far, so good.....

--------snip--------
Configured with: /GCC/gcc-3.3.1-3/configure --with-gcc --with-gnu-ld
--with-gnu-
as --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
--libexe
cdir=/usr/sbin --mandir=/usr/share/man --infodir=/usr/share/info
--enable-langua
ges=c,ada,c++,f77,pascal,java,objc --enable-libgcj --enable-threads=posix
--with
-system-zlib --enable-nls --without-included-gettext --enable-interpreter
--enab
le-sjlj-exceptions --disable-version-specific-runtime-libs --enable-shared
--dis
able-win32-registry --enable-java-gc=boehm --disable-hash-synchronization
--verb
ose --target=i686-pc-cygwin --host=i686-pc-cygwin --build=i686-pc-cygwin
Thread model: posix
gcc version 3.3.1 (cygming special)
 /usr/lib/gcc-lib/i686-pc-mingw32/3.3.1/cc1.exe -E -quiet -v -D__GNUC__=3
-D__GN
UC_MINOR__=3 -D__GNUC_PATCHLEVEL__=1 -D__MSVCRT__ -D__MINGW32__ -DWIN32
-D_WIN32
 -D__WIN32 -D__WIN32__ -DWINNT -idirafter
/usr/lib/gcc-lib/i686-pc-mingw32/3.3.1
/../../../../include/w32api -idirafter
/usr/lib/gcc-lib/i686-pc-mingw32/3.3.1/..
/../../../i686-pc-mingw32/lib/../../include/w32api - -mno-cygwin
--------snip--------

  And that's good: it's found the correct cc1 and has passed it all mingw
directories
on the command line.  No problem yet then.

--------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.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


--
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 -