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

["Terry Lincoln" <lincoln2 at rochester dot rr dot com>]

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