Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com X-Authentication-Warning: abomination.cygnus.com: mdejong owned process doing -bs Date: Sat, 15 Apr 2000 01:48:25 -0700 (PDT) From: Mo DeJong To: Mumit Khan cc: cygwin AT sourceware DOT cygnus DOT com Subject: Re: Mingwin does not seem to know where its headers live. In-Reply-To: <200004150327.WAA00787@hp2.xraylith.wisc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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 #include 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 AT sourceware DOT cygnus DOT com