This is the mail archive of the 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]

Re: Mingwin does not seem to know where its headers live.

On Fri, 14 Apr 2000, Mumit Khan wrote:

> Mo DeJong <> writes:
> > 
> > Here is the output I get from gcc when I compile the above code
> > with the -v option. (I am running with the new "net release" gcc)
> Exactly what I needed, thanks. As a bit of background, here's how
> -mno-cygwin "redirects" the include path: it basically adds the
> -iwithprefix <relative_path> option you see marked with ^^^^^^ below.
> The path is relative to gcc's "compiler" directory which contains
> cc1, specs etc.
> Could you please see if the relative path is not accessible and if
> not, investigate why? What relative path needed to get from the
> compiler directory to the mingw32 include directory?
> > $ gcc -c -mno-cygwin WIN32.C -v
> > Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/specs
> > gcc version 2.95.2 19991024 (release)
> >  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/cpp.exe -lang-c++ -v -D__GNUC__=2
> > -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -Di386 -D_WIN32 -DWINNT
> > -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__))
> > -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x))
> > -D__i386__ -D_WIN32 -D__WINNT__ -D_X86_=1 -D__STDC__=1
> > -D__stdcall=__attribute__((__stdcall__))
> > -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x))
> > -D__i386 -D__WINNT -Asystem(winnt) -Acpu(i386) -Amachine(i386)
> > -D__EXCEPTIONS -remap -Acpu(i386) -Amachine(i386) -Di386 -D__i386
> > -D__i386__ -Di686 -Dpentiumpro -D__i686 -D__i686__ -D__pentiumpro
> > -D__pentiumpro__ -iwithprefixbefore
> > ../../../../i686-pc-cygwin/include/mingw32 -D__MINGW32__=0.2 WIN32.C
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > C:\WINDOWS\TEMP/cccmAW4e.ii
> > GNU CPP version 2.95.2 19991024 (release) (80386, BSD syntax)
> > #include "..." search starts here:
> > #include <...> search starts here:
> >  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include/g++-3
> >  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include
> >  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/include
> >  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/include
> >  /usr/include
> [ snipped: FAT case brain-damage causeing win32.c vs WIN32.C and so on 
>   that I can't help with ]
> Regards,
> Mumit

I did some more digging and it looks like the problem does
not get solved by using a file with the .c extension instead
of the .C extension. Here is the output I got with the same
file renamed to lower.c.

% cat lower.c 
#include <string.h>
#include <direct.h>

int main(int argc, char ** argv) {
    return 0;

BASH.EXE-2.03$ gcc -v -c -mno-cygwin lower.c
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/specs
gcc version 2.95.2 19991024 (release)
 /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/cpp.exe -lang-c -v -D__GNUC__=2
-D__GNUC_MINOR__=95 -Di386 -D_WIN32 -DWINNT -D_X86_=1 -D__STDC__=1
-D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x))
-D__i386__ -D_WIN32
-D__WINNT__ -D_X86_=1 -D__STDC__=1
-D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x))
-D__i386 -D__WINNT -Asystem(winnt) -Acpu(i386) -Amachine(i386) -remap
-Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di686 -Dpentiumpro
-D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ -iwithprefixbefore
../../../../i686-pc-cygwin/include/mingw32 -D__MINGW32__=0.2 lower.c
GNU CPP version 2.95.2 19991024 (release) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
End of search list.
The following default directories have been omitted from the search path:
End of omitted list.
lower.c:2: direct.h: No such file or directory

There are two things that are worth looking into here.

First, when I compiled it tried to use 


instead of


Could that be the cause of the problem?

Second, I just do not see how the

Path could ever reach the mingwin include files.

When I tried to compile lower.c, my current working
directory was D:/Cygwin and the cygwin root was
mounted at C:/Cygwin.

Under cygwin, D:/Cygwin sees /cygdrive/d/Cygwin
as the current directory, so the relative path
would need to be set to:




Why not just make the -iwithprefixbefore
argument a fully qualified name (if such
a thing were possible).

There is also some wacky mounting going on
where /usr/bin is that same as /bin and so
on. I don't know if that has anything to
do with it. Perhaps gcc just does not know
if it is getting launched from /bin or /usr/bin.
I am still not exactly sure why we need
these strange mounts, would it really be
so bad to have both /bin and /usr/bin be
real directories?

Mo Dejong
Red Hat Inc.

Want to unsubscribe from this list?
Send a message to

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