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 Message-ID: <00f501bfa8f1$94cb4f40$c92c1818@rochester.rr.com> From: "Terry Lincoln" To: "Mo DeJong" , "Mumit Khan" Cc: References: Subject: Re: Mingwin does not seem to know where its headers live. Date: Tue, 18 Apr 2000 00:50:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 On Saturday, April 15, 2000 4:48 AM, Mo DeJong wrote: > 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 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 > #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 > > -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com