Mingwin does not seem to know where its headers live.

Mingwin does not seem to know where its headers live.

[Mo DeJong]

I am trying to compile this code.

BASH.EXE-2.03$ cat WIN32.C
#include <string.h>
#include <direct.h>

int main(int argc, char ** argv) {
    strcpy(NULL,NULL);
    mkdir(NULL);
    return 0;
}


When I build with mingwin, it bails out
saying it can not find direct.h.

BASH.EXE-2.03$ gcc -mno-cygwin -c WIN32.C
WIN32.C:2: direct.h: No such file or directory

But, if I provide the fully qualified path name
of mingwin's header directory it compiles.

BASH.EXE-2.03$ gcc -mno-cygwin -c WIN32.C
-I/usr/i686-pc-cygwin/include/mingw


Why does mingwin not know where its own
headers live? Am I doing something wrong?

Mo Dejong
Red Hat Inc.


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Larry Hall (RFK Partners, Inc)]

You need to set gcc up to recognize a MINGW type compile rather than a 
Cygwin compile.  You can't mix and match Cygwin stuff and MINGW stuff.
You need to play with your specs file some as I recall.  Check the mail
archives and/or Mumit Kahn's site for details...

Larry


At 11:46 AM 4/13/00, Mo DeJong wrote:
>I am trying to compile this code.
>
>BASH.EXE-2.03$ cat WIN32.C
>#include <string.h>
>#include <direct.h>
>
>int main(int argc, char ** argv) {
>     strcpy(NULL,NULL);
>     mkdir(NULL);
>     return 0;
>}
>
>
>When I build with mingwin, it bails out
>saying it can not find direct.h.
>
>BASH.EXE-2.03$ gcc -mno-cygwin -c WIN32.C
>WIN32.C:2: direct.h: No such file or directory
>
>But, if I provide the fully qualified path name
>of mingwin's header directory it compiles.
>
>BASH.EXE-2.03$ gcc -mno-cygwin -c WIN32.C
>-I/usr/i686-pc-cygwin/include/mingw
>
>
>Why does mingwin not know where its own
>headers live? Am I doing something wrong?
>
>Mo Dejong
>Red Hat Inc.
>
>
>--
>Want to unsubscribe from this list?
>Send a message to cygwin-unsubscribe@sourceware.cygnus.com



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Mumit Khan]

Mo DeJong <mdejong@cygnus.com> writes:
> I am trying to compile this code.
> 
> BASH.EXE-2.03$ cat WIN32.C
> #include <string.h>
> #include <direct.h>
> 
> int main(int argc, char ** argv) {
>     strcpy(NULL,NULL);
>     mkdir(NULL);
>     return 0;
> }
> 
> 
> When I build with mingwin, it bails out
> saying it can not find direct.h.
> 
> BASH.EXE-2.03$ gcc -mno-cygwin -c WIN32.C
> WIN32.C:2: direct.h: No such file or directory

Sorry, but this report provides me with no information that
may help tracking down the problem.

You need to tell us what version of gcc, and provide some information 
on what version Cygwin, and if you're using a Cygwin snapshot vs one
of the released versions, and so on. At the very least, look at the 
output of:

  BASH.EXE-2.03$ gcc -v -mno-cygwin -c WIN32.C

-mno-cygwin uses some internal magic to find the path to the Mingw
includes, and obviously it's failing here. Hopefully the -v option
will point us in the right direction.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Mo DeJong]

On Thu, 13 Apr 2000, Mumit Khan wrote:

> Mo DeJong <mdejong@cygnus.com> writes:
> > I am trying to compile this code.
> > 
> > BASH.EXE-2.03$ cat WIN32.C
> > #include <string.h>
> > #include <direct.h>
> > 
> > int main(int argc, char ** argv) {
> >     strcpy(NULL,NULL);
> >     mkdir(NULL);
> >     return 0;
> > }
> > 
> > 
> > When I build with mingwin, it bails out
> > saying it can not find direct.h.
> > 
> > BASH.EXE-2.03$ gcc -mno-cygwin -c WIN32.C
> > WIN32.C:2: direct.h: No such file or directory

I was using a pre release of the new "net release" of cygwin.
The strange thing is, I have also seen this problem in the
B.20 release on 95 and an internal cygwin-991019 release that
I had installed on a NT box.

> Sorry, but this report provides me with no information that
> may help tracking down the problem.
> 
> You need to tell us what version of gcc, and provide some information 
> on what version Cygwin, and if you're using a Cygwin snapshot vs one
> of the released versions, and so on. At the very least, look at the 
> output of:

I will be sure to run this when I get home tonight. I have the
net release installed on my laptop at home.

>   BASH.EXE-2.03$ gcc -v -mno-cygwin -c WIN32.C
> 
> -mno-cygwin uses some internal magic to find the path to the Mingw
> includes, and obviously it's failing here. Hopefully the -v option
> will point us in the right direction.
> 
> Regards,
> Mumit

Mo Dejong
Red Hat Inc.



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Mo DeJong]

On Thu, 13 Apr 2000, Mumit Khan wrote:

> Mo DeJong <mdejong@cygnus.com> writes:
> > I am trying to compile this code.
> > 
> > BASH.EXE-2.03$ cat WIN32.C
> > #include <string.h>
> > #include <direct.h>
> > 
> > int main(int argc, char ** argv) {
> >     strcpy(NULL,NULL);
> >     mkdir(NULL);
> >     return 0;
> > }
> > 
> > 
> > When I build with mingwin, it bails out
> > saying it can not find direct.h.
> > 
> > BASH.EXE-2.03$ gcc -mno-cygwin -c WIN32.C
> > WIN32.C:2: direct.h: No such file or directory
> 
> Sorry, but this report provides me with no information that
> may help tracking down the problem.
> 
> You need to tell us what version of gcc, and provide some information 
> on what version Cygwin, and if you're using a Cygwin snapshot vs one
> of the released versions, and so on. At the very least, look at the 
> output of:
> 
>   BASH.EXE-2.03$ gcc -v -mno-cygwin -c WIN32.C
> 
> -mno-cygwin uses some internal magic to find the path to the Mingw
> includes, and obviously it's failing here. Hopefully the -v option
> will point us in the right direction.
> 
> Regards,
> Mumit

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)

$ 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
End of search list.
The following default directories have been omitted from the search path:
End of omitted list.
WIN32.C:2: direct.h: No such file or directory

So it only searched i686-pc-cygwin/include and not the mingwin includes.

Notice how it invoked cpp.exe with -lang-c++, could that be what is
hosing it up. This really is just a regular C file, not a C++ one,
it just got named that way when I copied it over from Linux. Whats
odd about that is that when I mount the same drive under linux, it
sees the file name as win32.c (not WIN32.C).

Mo Dejong
Red Hat Inc.


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Mumit Khan]

Mo DeJong <mdejong@cygnus.com> 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


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Mo DeJong]

On Fri, 14 Apr 2000, Mumit Khan wrote:

> Mo DeJong <mdejong@cygnus.com> 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) {
    strcpy(NULL,NULL);
    mkdir(NULL);
    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__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) -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
C:\WINDOWS\TEMP/ccJnwakd.i
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
 /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
End of search list.
The following default directories have been omitted from the search path:
 /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include/g++-3
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 

/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/cpp.exe

instead of

/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/cc1.exe

Could that be the cause of the problem?

Second, I just do not see how the
../../../../i686-pc-cygwin/include/mingw32

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:

../../usr/i686-pc-cygwin/include/mingw

NOT

../../../../i686-pc-cygwin/include/mingw32


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 cygwin-unsubscribe@sourceware.cygnus.com

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

[Terry Lincoln]

On Saturday, April 15, 2000 4:48 AM, Mo DeJong <mdejong@cygnus.com> wrote:

> On Fri, 14 Apr 2000, Mumit Khan wrote:
>
> > Mo DeJong <mdejong@cygnus.com> 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

The canonicalized path returns thus (from line above):
1)
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/include/mi
ngw32
2) /usr/lib/gcc-lib/i686-pc-cygwin/../../../i686-pc-cygwin/include/mingw32
3) /usr/lib/gcc-lib/../../i686-pc-cygwin/include/mingw32
4) /usr/lib/../i686-pc-cygwin/include/mingw32
5) /usr/i686-pc-cygwin/include/mingw32
Thus that /usr/i686-pc-cygwin/include/mingw32 is the place being searched.
You should look in that directory and make sure it is correct.

Warm Regards,

W. Terry Lincoln
> > >  /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) {
>     strcpy(NULL,NULL);
>     mkdir(NULL);
>     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__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) -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
> C:\WINDOWS\TEMP/ccJnwakd.i
> 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
>  /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
> End of search list.
> The following default directories have been omitted from the search path:
>  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../include/g++-3
> 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
>
> /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/cpp.exe
>
> instead of
>
> /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/cc1.exe
>
> Could that be the cause of the problem?
>
> Second, I just do not see how the
> ../../../../i686-pc-cygwin/include/mingw32
>
> 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:
>
> ../../usr/i686-pc-cygwin/include/mingw
>
> NOT
>
> ../../../../i686-pc-cygwin/include/mingw32
>
>
> 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 cygwin-unsubscribe@sourceware.cygnus.com
>
>


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Heribert Dahms]

Hi Mo,

try: mv WIN32.C win32.c
or override gcc language (forgot the switch)

Bye, Heribert (heribert_dahms@icon-gmbh.de)

> -----Original Message-----
> From:	Mo DeJong [SMTP:mdejong@cygnus.com]
> Sent:	Friday, April 14, 2000 09:14
> To:	Mumit Khan
> Cc:	cygwin@sourceware.cygnus.com
> Subject:	Re: Mingwin does not seem to know where its headers
> live. 
> 
> On Thu, 13 Apr 2000, Mumit Khan wrote:
> 
> > Mo DeJong <mdejong@cygnus.com> writes:
> > > I am trying to compile this code.
> > > 
> > > BASH.EXE-2.03$ cat WIN32.C
> > > #include <string.h>
> > > #include <direct.h>
> > > 
> > > int main(int argc, char ** argv) {
> > >     strcpy(NULL,NULL);
> > >     mkdir(NULL);
> > >     return 0;
> > > }
> > > 
> > > 
> > > When I build with mingwin, it bails out
> > > saying it can not find direct.h.
> > > 
> > > BASH.EXE-2.03$ gcc -mno-cygwin -c WIN32.C
> > > WIN32.C:2: direct.h: No such file or directory
> > 
> > Sorry, but this report provides me with no information that
> > may help tracking down the problem.
> > 
> > You need to tell us what version of gcc, and provide some
> information 
> > on what version Cygwin, and if you're using a Cygwin snapshot vs one
> > of the released versions, and so on. At the very least, look at the 
> > output of:
> > 
> >   BASH.EXE-2.03$ gcc -v -mno-cygwin -c WIN32.C
> > 
> > -mno-cygwin uses some internal magic to find the path to the Mingw
> > includes, and obviously it's failing here. Hopefully the -v option
> > will point us in the right direction.
> > 
> > Regards,
> > Mumit
> 
> 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)
> 
> $ 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/incl
> ude
>  /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/include
>  /usr/include
> End of search list.
> The following default directories have been omitted from the search
> path:
> End of omitted list.
> WIN32.C:2: direct.h: No such file or directory
> 
> So it only searched i686-pc-cygwin/include and not the mingwin
> includes.
> 
> Notice how it invoked cpp.exe with -lang-c++, could that be what is
> hosing it up. This really is just a regular C file, not a C++ one,
> it just got named that way when I copied it over from Linux. Whats
> odd about that is that when I mount the same drive under linux, it
> sees the file name as win32.c (not WIN32.C).
> 
> Mo Dejong
> Red Hat Inc.
> 
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Earnie Boyd]

--- Charles Wilson <cwilson@ece.gatech.edu> wrote:
> Earnie - 
>  Thank you for this explanation. I've been on this list for ages, but
> never quite understood the diffference between MinGW and -mno-cygwin.
> This should be a *cygwin* FAQ.
> 

Good point.  Cygnus/Redhat has my permission to include the verbage even
modified into the FAQ.


=====
---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://www.freeyellow.com/members5/gw32/index.html >
           __Minimalist GNU for Windows__
  Mingw32 List: < http://www.egroups.com/group/mingw32/ >
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Charles Wilson]

Earnie - 
 Thank you for this explanation. I've been on this list for ages, but
never quite understood the diffference between MinGW and -mno-cygwin.
This should be a *cygwin* FAQ.

--Chuck


Earnie Boyd wrote:
> 
> --- Mo DeJong <mdejong@cygnus.com> wrote:
> -8<-
> > When I build with mingwin, it bails out
> > saying it can not find direct.h.
> >
> > BASH.EXE-2.03$ gcc -mno-cygwin -c WIN32.C
> > WIN32.C:2: direct.h: No such file or directory
> >
> -8<-
> 
> I'm going to get picky here.  Using Cygwin gcc with the -mno-cygwin switch is
> not MinGW.  There is a different gcc which Mumit distributes that is native to
> Win32 and thus is the MinGW GCC toolset.  You can get this from the pointers at
> http://www.mingw.org .
> 
> Using the -mno-cygwin switch is sort of a cross compile.  You have a separate
> set of headers, a separate set of libraries and a special switch which is
> controlled via the specs file.
> 
> Mumit has on his site a "howto" for using the -mno-cygwin switch successfully.
> This information is in the volumes of archives.
> 
> Regards,
> 
> =====
> ---
>    Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
>             __Cygwin: POSIX on Windows__
> Cygwin Newbies: < http://www.freeyellow.com/members5/gw32/index.html >
>            __Minimalist GNU for Windows__
>   Mingw32 List: < http://www.egroups.com/group/mingw32/ >
>     Mingw Home: < http://www.mingw.org/ >
> 
> __________________________________________________
> Do You Yahoo!?
> Send online invitations with Yahoo! Invites.
> http://invites.yahoo.com
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Earnie Boyd]

--- Mo DeJong <mdejong@cygnus.com> wrote:
-8<-
> When I build with mingwin, it bails out
> saying it can not find direct.h.
> 
> BASH.EXE-2.03$ gcc -mno-cygwin -c WIN32.C
> WIN32.C:2: direct.h: No such file or directory
> 
-8<-

I'm going to get picky here.  Using Cygwin gcc with the -mno-cygwin switch is
not MinGW.  There is a different gcc which Mumit distributes that is native to
Win32 and thus is the MinGW GCC toolset.  You can get this from the pointers at
http://www.mingw.org .

Using the -mno-cygwin switch is sort of a cross compile.  You have a separate
set of headers, a separate set of libraries and a special switch which is
controlled via the specs file.

Mumit has on his site a "howto" for using the -mno-cygwin switch successfully. 
This information is in the volumes of archives.

Regards,

=====
---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://www.freeyellow.com/members5/gw32/index.html >
           __Minimalist GNU for Windows__
  Mingw32 List: < http://www.egroups.com/group/mingw32/ >
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com