This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: gcc -mno-cygwin finds the wrong include files

Has anyone else been able to confirm this as a bug? if so, any attempts to
fix it?


-----Original Message-----
From: Dave Korn []
Sent: Tuesday, April 13, 2004 1:08 PM
Subject: RE: gcc -mno-cygwin finds the wrong include files

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

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

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

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

  So far, so good.....

Configured with: /GCC/gcc-3.3.1-3/configure --with-gcc --with-gnu-ld
as --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
cdir=/usr/sbin --mandir=/usr/share/man --infodir=/usr/share/info
ges=c,ada,c++,f77,pascal,java,objc --enable-libgcj --enable-threads=posix
-system-zlib --enable-nls --without-included-gettext --enable-interpreter
le-sjlj-exceptions --disable-version-specific-runtime-libs --enable-shared
able-win32-registry --enable-java-gc=boehm --disable-hash-synchronization
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__WIN32 -D__WIN32__ -DWINNT -idirafter
/../../../../include/w32api -idirafter
/../../../i686-pc-mingw32/lib/../../include/w32api - -mno-cygwin

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

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:

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

End of search list.

  I noticed this rather peculiar entry in the specs file:


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.

Can't think of a witty .sigline today....

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]