From: Rolf E. <rol...@we...> - 2004-01-22 16:13:43
|
Earnie schrieb am 22.01.04 12:49:37: > 1) MSYS doesn't understand what a /cygdrive is; just remove /cygdrive > from the specified path. The /cygdrive part is generated when configuring in a cygwin shell. Doing the same in a Msys shell does not include it. But that is not the problem. > 2) You don't specify the --build=mingw32 so the configure script is > thinking your a building in a cross environment so it looks in the > target directory /mingw/mingw32 for the include directory for the system > headers. > a) I'm not certain that including --build=mingw32 will change that > result. I have just copied the options that the precompiled gcc-3.3.1 reports in it's spec file: $ gcc -v Reading specs from d:/Programme/MinGW-3.1.0/bin/../lib/gcc-lib/mingw32/3.3.1/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,objc,ada,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization Thread model: win32 gcc version 3.3.1 (mingw special 20030804-1) It does not mention a --build option. I am not really sure if building from a cygwin shell is actually building a cross-compiler. Is it? > b) There is also an --oldinclude configure switch that may help. I'll have to try that one. > 3) Don't specify the bootstrap Makefile target and see if that helps. Do you mean, just "make" in lieu of "make bootstrap". (BTW, I used "make bootstrap-lean"). I shall try that, too. ----- I have investigated a bit more. After the compilation stopped, I issued the last command manually and added the -v option (this time configuring and making in a Msys shell): $ ./xgcc -v -B./ -B/mingw/mingw32/bin/ -isystem /mingw/mingw32/include -isystem /mingw/mingw32/sys-include -O2 -I../../gcc-3.3.2/gcc/../winsup/include -I../../gcc-3.3.2/gcc/../winsup/cygwin/include -I../../gcc-3.3.2/gcc/../winsup/w32api/include -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-3.3.2/gcc -I../../gcc-3.3.2/gcc/. -I../../gcc-3.3.2/gcc/config -I../../gcc-3.3.2/gcc/../include -DL_muldi3 -c ../../gcc-3.3.2/gcc/libgcc2.c -o libgcc/./_muldi3.o Reading specs from .\specs Configured with: ../gcc-3.3.2/configure --host=mingw32 --target=mingw32 --prefix=/mingw --disable-threads --disable-nls --enable-languages=c --disable-win32-registry --enable-sjlj-exceptions Thread model: single gcc version 3.3.2 .\cc1.exe -quiet -v -I../../gcc-3.3.2/gcc/../winsup/include -I../../gcc-3.3.2/gcc/../winsup/cygwin/include -I../../gcc-3.3.2/gcc/../winsup/w32api/include -I. -I. -I../../gcc-3.3.2/gcc -I../../gcc-3.3.2/gcc/. -I../../gcc-3.3.2/gcc/config -I../../gcc-3.3.2/gcc/../include -iprefix d:\Data\Development\gcc-cvs\build-mingw\gcc\../lib/gcc-lib/mingw32\3.3.2\ -isystem .\include -isystem d:\Programme\MinGW-3.1.0\mingw32\bin\include -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=2 -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DL_muldi3 -isystem d:/Programme/MinGW-3.1.0/mingw32/include -isystem d:/Programme/MinGW-3.1.0/mingw32/sys-include -isystem ./include ../../gcc-3.3.2/gcc/libgcc2.c -quiet -dumpbase libgcc2.c -auxbase-strip libgcc/./_muldi3.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -version -o C:/DOKUME~1/ebert/LOKALE~1/Temp/ccGIaaaa.s ignoring nonexistent directory "../../gcc-3.3.2/winsup/include" ignoring nonexistent directory "../../gcc-3.3.2/winsup/cygwin/include" ignoring nonexistent directory "../../gcc-3.3.2/winsup/w32api/include" ignoring nonexistent directory "d:/Programme/MinGW-3.1.0/mingw32/bin/include" ignoring nonexistent directory "d:/Programme/MinGW-3.1.0/mingw32/include" ignoring nonexistent directory "d:/Programme/MinGW-3.1.0/mingw32/sys-include" GNU C version 3.3.2 (mingw32) compiled by GNU C version 3.3.1 (mingw special 20030804-1). GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=65467 ignoring nonexistent directory "d:/Data/Development/gcc-cvs/build-mingw/lib/gcc-lib/mingw32/3.3.2/include" ignoring nonexistent directory "C:/msys/1.0.10rc3/local/include" ignoring nonexistent directory "/mingw/include" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ignoring nonexistent directory "d:/Programme/MinGW-3.1.0/lib/gcc-lib/mingw32/3.3.2/include" ignoring nonexistent directory "d:/Programme/MinGW-3.1.0/mingw32/include" ignoring nonexistent directory "/usr/local/mingw32/include" #include "..." search starts here: #include <...> search starts here: . . ../../gcc-3.3.2/gcc ../../gcc-3.3.2/gcc ../../gcc-3.3.2/gcc/config ../../gcc-3.3.2/include include include End of search list. ... You can see that cc1 pretends that the directory /mingw/include does not exist. Sure it does not find the system headers if gcc does not even care to look in the directory where they actually are. The question is now, why does the stage1 compiler not recognize /mingw/include as an existing directory? BTW. http://gcc.gnu.org/PR12974 seems at least related, if not the same problem. Rolf ______________________________________________________________________________ Erdbeben im Iran: Zehntausende Kinder brauchen Hilfe. UNICEF hilft den Kindern - helfen Sie mit! https://www.unicef.de/spe/spe_03.php |
From: Rolf E. <rol...@we...> - 2004-01-23 15:20:44
|
Danny schrieb am 23.01.04 12:18:04: > > --- Rolf Ebert <rol...@we...> wrote: > > ignoring nonexistent directory "/mingw/include" > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > The question is now, why does the stage1 compiler not recognize /mingw/include as an > > existing directory? > > /mingw/include == d:/mingw/include in your case, because d: is current drive Are you sure? I thought the mount should take care of that. I.e. /mingw is mounted on D:/Programme/MinGW-3.1.0. That should be true independently from the current drive. Is there still the notion of a "current drive" in Msys? > The simplest fix is to do everything from one drive. There are other ways using environment > variables, but I would try the simple way first. OK. I reinstalled everything on a single drive (D:) Windows 2000 SP3 msys 1.0.10rc3 D:\msys\1.0.10rc3 MinGW 3.1.0 D:\Programme\MinGW-3.1.0 runtime 3.2 extracted in /mingw win32api 2.4 extracted in /mingw gcc sources D:\Data\Development\gcc-cvs\gcc-3.3.2 build dir D:\Data\Development\gcc-cvs\build-mingw I tried several configure options (oldincludedir, with-headers) to no avail. It still fails in the same manner. The stage1 compiler does still not recognize /mingw/include as a directory. I therefor had a look at the gcc sources (cppinit.c) and suspected a misbehaviour of the corresponding stat call. The simple test program below clearly shows my problem: #include <stdio.h> #include <string.h> #include <sys/types.h> #include <sys/stat.h> #include <errno.h> static const char default_dir[] = "/mingw/include"; int main(int argc, char* argv[]) { struct stat st; int res, i; char * dir; if (argc < 2) { argc = 2; argv[1] = default_dir; } for (i = 1; i < argc; i++) { dir = argv[i]; printf("stat'ing \"%s\"\t\t", dir); res = stat (dir, &st); if (res != 0) { printf("stat result: %d, errno: %d, strerror: %s\n", res, errno, strerror(errno)); } else { printf("stat result: %d\n", res); } } return 0; } ---- If I call it with /mingw/include (shell and everthing else on drive D:) as parameter is answers: $ ./a /mingw/include stat'ing "d:/Programme/MinGW-3.1.0/include" stat result: 0 If I call it without parameter it answers: $ ./a stat'ing "/mingw/include" stat result: -1, errno: 2, strerror: No such file or directory Can anybody explain or at least confirm the same behaviour on your installation? TIA Rolf ______________________________________________________________________________ Erdbeben im Iran: Zehntausende Kinder brauchen Hilfe. UNICEF hilft den Kindern - helfen Sie mit! https://www.unicef.de/spe/spe_03.php |
From: Earnie B. <ea...@us...> - 2004-01-27 11:40:04
|
Rolf Ebert wrote: > > If I call it with /mingw/include (shell and everthing else on drive D:) as parameter is answers: > $ ./a /mingw/include > stat'ing "d:/Programme/MinGW-3.1.0/include" stat result: 0 > > If I call it without parameter it answers: > $ ./a > stat'ing "/mingw/include" stat result: -1, errno: 2, strerror: No such file or directory > > Can anybody explain or at least confirm the same behaviour on your installation? > This is the expected result. MSYS is a tool that translates the POSIX to the WIN32 path when it is spawning the MSVCRT dependent binary. The same binary will not on its own translate the path as the output of your test program confirms. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Luke D. <cod...@ho...> - 2004-01-26 13:32:34
|
----- Original Message ----- From: "Rolf Ebert" <rol...@we...> To: <min...@li...> Sent: Friday, January 23, 2004 11:20 PM Subject: Re: [Mingw-users] Problem boostrapping gcc > Danny schrieb am 23.01.04 12:18:04: > > > > --- Rolf Ebert <rol...@we...> wrote: > > > ignoring nonexistent directory "/mingw/include" > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > The question is now, why does the stage1 compiler not recognize /mingw/include as an > > > existing directory? > > > > /mingw/include == d:/mingw/include in your case, because d: is current drive > > Are you sure? I thought the mount should take care of that. I.e. /mingw is mounted on > D:/Programme/MinGW-3.1.0. That should be true independently from the current drive. > Is there still the notion of a "current drive" in Msys? MSYS can't make normal Win32 programs magically understand mount points, it can only translate them on the command line and in environment variables, so all of this behaviour is as expected. Only MSYS programs like sh.exe can access POSIX paths directly. One simple but inconvenient way to get around this when bootstrapping GCC is by having everything on one drive and making sure "/mingw" is mounted on "c:\mingw". Another way that has worked for me in the past is to use a configure command like "configure --prefix=c:/foo/mingw". Also, you could just do "make" instead of "make bootstrap". Luke |
From: Rolf E. <rol...@we...> - 2004-01-27 17:18:36
|
Sorry for some probably very stupid error on my installation. I am confused now. I still try to understand my bootstrapping problem. > This is the expected result. MSYS is a tool that translates the POSIX > to the WIN32 path when it is spawning the MSVCRT dependent binary. The > same binary will not on its own translate the path as the output of your > test program confirms. 1) The symptom is that the stage1 cc1.exe does not find the system headers located at /mingw/include. 2) The standard system include directory (/usr/include on Unix, /mingw/include on MinGW) is not explicitely provided as a "-I" option to the compiler. The path is rather compiled into the binary. 3) A path provided as command line parameter is expanded (translated) by the MSYS shell into a WIN32 path. (Usual) binaries cannot translate POSIX paths to WIN32 paths. 4) cc1.exe is a MSVCRT dependent binary (?), it therefor cannot expand the compiled-in system path. How is bootstrapping supposed to work? Thanks for your patience. Rolf ______________________________________________________________________________ Erdbeben im Iran: Zehntausende Kinder brauchen Hilfe. UNICEF hilft den Kindern - helfen Sie mit! https://www.unicef.de/spe/spe_03.php |
From: Luke D. <cod...@ho...> - 2004-01-28 01:30:06
|
I thought I had already replied to you but I guess I must have made a mistake somewhere. Anyway, my suggestions are to either: 1. Mount d:/mingw as /mingw and build on drive D or 2. Configure with "--prefix=d:/programme/mingw-3.1.0" instead or 3. Modify the GCC sources and/or configure scripts somehow to get it to work with the default configure options. Since this option is a lot more difficult than the above two, that's why it doesn't currently work out of the box. There are no guarantees though, because the binaries released by MinGW are built with "make" not "make bootstrap" AFAIK. Luke >From: "Rolf Ebert" <rol...@we...> >Reply-To: min...@li... >To: min...@li... >Subject: Re: [Mingw-users] Problem boostrapping gcc >Date: Tue, 27 Jan 2004 18:18:19 +0100 > >Sorry for some probably very stupid error on my installation. I am confused >now. I still try to understand my bootstrapping problem. > > > This is the expected result. MSYS is a tool that translates the POSIX > > to the WIN32 path when it is spawning the MSVCRT dependent binary. The > > same binary will not on its own translate the path as the output of your > > test program confirms. > > >1) The symptom is that the stage1 cc1.exe does not find the system headers >located at /mingw/include. > >2) The standard system include directory (/usr/include on Unix, >/mingw/include on MinGW) is not explicitely provided as a "-I" option to >the compiler. The path is rather compiled into the binary. > >3) A path provided as command line parameter is expanded (translated) by >the MSYS shell into a WIN32 path. (Usual) binaries cannot translate POSIX >paths to WIN32 paths. > >4) cc1.exe is a MSVCRT dependent binary (?), it therefor cannot expand the >compiled-in system path. > >How is bootstrapping supposed to work? > >Thanks for your patience. > > Rolf _________________________________________________________________ E-mail just got a whole lot better. New ninemsn Premium. Click here http://ninemsn.com.au/premium/landing.asp |
From: <dan...@ya...> - 2004-01-28 04:05:21
|
--- Luke Dunstan <cod...@ho...> wrote: > > > 3. Modify the GCC sources and/or configure scripts somehow to get it to work > with the default configure options. Since this option is a lot more > difficult than the above two, that's why it doesn't currently work out of > the box. > > There are no guarantees though, because the binaries released by MinGW are > built with "make" not "make bootstrap" AFAIK. > No, they are built with "make bootstrap". On trunk, no modification is necessary for configure or sources. Om 3.3 branch and earlier add an x-mingw32 file to config/i386. It should contain (at least) # # Make local_include_dir relative to EXEC_PREFIX # local_includedir=$(libsubdir)/$(unlibsubdir)/..`echo $(exec_prefix) | sed -e 's|^$(prefix)||' -e 's|/[^/]*|/..|g'`/include (unwrap the above line). add x-mingw32 as xmake frag to config.gcc All this is with cygwin environ and with D:\\ mounted as / Danny > Luke > > > >From: "Rolf Ebert" <rol...@we...> > >Reply-To: min...@li... > >To: min...@li... > >Subject: Re: [Mingw-users] Problem boostrapping gcc > >Date: Tue, 27 Jan 2004 18:18:19 +0100 > > > >Sorry for some probably very stupid error on my installation. I am confused > >now. I still try to understand my bootstrapping problem. > > > > > This is the expected result. MSYS is a tool that translates the POSIX > > > to the WIN32 path when it is spawning the MSVCRT dependent binary. The > > > same binary will not on its own translate the path as the output of your > > > test program confirms. > > > > > >1) The symptom is that the stage1 cc1.exe does not find the system headers > >located at /mingw/include. > > > >2) The standard system include directory (/usr/include on Unix, > >/mingw/include on MinGW) is not explicitely provided as a "-I" option to > >the compiler. The path is rather compiled into the binary. > > > >3) A path provided as command line parameter is expanded (translated) by > >the MSYS shell into a WIN32 path. (Usual) binaries cannot translate POSIX > >paths to WIN32 paths. > > > >4) cc1.exe is a MSVCRT dependent binary (?), it therefor cannot expand the > >compiled-in system path. > > > >How is bootstrapping supposed to work? > > > >Thanks for your patience. > > > > Rolf > > _________________________________________________________________ > E-mail just got a whole lot better. New ninemsn Premium. Click here > http://ninemsn.com.au/premium/landing.asp > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://personals.yahoo.com.au - Yahoo! Personals New people, new possibilities. FREE for a limited time. |
From: Rolf E. <rol...@we...> - 2004-01-31 02:24:35
|
Luke schrieb: > I thought I had already replied to you but I guess I must have made a > mistake somewhere. Anyway, my suggestions are to either: I actually received this message a few hours before the one you sent out earlier. > 1. Mount d:/mingw as /mingw and build on drive D This one works fine! Thank you very much. > or > > 2. Configure with "--prefix=d:/programme/mingw-3.1.0" instead I think I had tried that before and it failed. I shall test it again. > or > > 3. Modify the GCC sources and/or configure scripts somehow to get it to work > with the default configure options. Since this option is a lot more > difficult than the above two, that's why it doesn't currently work out of > the box. I shall try Danny's description in <200...@we...> of porting the Makefile trickery from trunk to the gcc-3.3 branch, too. BTW. gcc-3.3.2 bootstrap ends with the following error message: Bootstrap comparison failure! gcse.o differs insn-emit.o differs ra-build.o differs I do not consider that a problem, although it is a bit astonishing. Thanks to everybody for your patience and help. Rolf ______________________________________________________________________________ Erdbeben im Iran: Zehntausende Kinder brauchen Hilfe. UNICEF hilft den Kindern - helfen Sie mit! https://www.unicef.de/spe/spe_03.php |
From: <dan...@ya...> - 2004-01-23 10:44:47
|
--- Rolf Ebert <rol...@we...> wrote: > Earnie schrieb am 22.01.04 12:49:37: > ignoring nonexistent directory "../../gcc-3.3.2/winsup/include" > ignoring nonexistent directory "../../gcc-3.3.2/winsup/cygwin/include" > ignoring nonexistent directory "../../gcc-3.3.2/winsup/w32api/include" > ignoring nonexistent directory "d:/Programme/MinGW-3.1.0/mingw32/bin/include" > ignoring nonexistent directory "d:/Programme/MinGW-3.1.0/mingw32/include" > ignoring nonexistent directory "d:/Programme/MinGW-3.1.0/mingw32/sys-include" > GNU C version 3.3.2 (mingw32) > compiled by GNU C version 3.3.1 (mingw special 20030804-1). > GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=65467 > ignoring nonexistent directory > "d:/Data/Development/gcc-cvs/build-mingw/lib/gcc-lib/mingw32/3.3.2/include" > ignoring nonexistent directory "C:/msys/1.0.10rc3/local/include" > ignoring nonexistent directory "/mingw/include" > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ignoring nonexistent directory "d:/Programme/MinGW-3.1.0/lib/gcc-lib/mingw32/3.3.2/include" > ignoring nonexistent directory "d:/Programme/MinGW-3.1.0/mingw32/include" > ignoring nonexistent directory "/usr/local/mingw32/include" > #include "..." search starts here: > #include <...> search starts here: > . > . > ../../gcc-3.3.2/gcc > ../../gcc-3.3.2/gcc > ../../gcc-3.3.2/gcc/config > ../../gcc-3.3.2/include > include > include > End of search list. > ... > > You can see that cc1 pretends that the directory /mingw/include does not exist. Sure it does not > find the system headers if gcc does not even care to look in the directory where they actually > are. > > The question is now, why does the stage1 compiler not recognize /mingw/include as an existing > directory? /mingw/include == d:/mingw/include in your case, because d: is current drive The simplest fix is to do everything from one drive. There are other ways using environment variables, but I would try the simple way first. > > BTW. http://gcc.gnu.org/PR12974 seems at least related, if not the same problem. No, if you read that message, that problem is only apparent on 3.4 and trunk. The error messages are different. I'd guess that 12974 is due to some 'sysroot' shenanigans, but I can't reproduce on my build systems Danny > > Rolf > > ______________________________________________________________________________ > Erdbeben im Iran: Zehntausende Kinder brauchen Hilfe. UNICEF hilft den > Kindern - helfen Sie mit! https://www.unicef.de/spe/spe_03.php > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://personals.yahoo.com.au - Yahoo! Personals New people, new possibilities. FREE for a limited time. |