From: Stefan B. <sb...@sb...> - 2005-10-23 13:05:49
|
I need a MinGW g++ (based on 3.4) that is configured with sjlj exceptions disabled. Has anybody already built that configuration? If not, I'll have to build one myself. Is there anywhere documentation of how to build MinGW from the source and what is required to do so? -- Stefan Bellon |
From: Michael G. <mg...@te...> - 2005-10-23 14:14:13
|
> I need a MinGW g++ (based on 3.4) that is configured with sjlj > exceptions disabled. Has anybody already built that configuration? If > not, I'll have to build one myself. Is there anywhere documentation of > how to build MinGW from the source and what is required to do so? The script and options used by Danny to create the stock version of MinGW g++ can be downloaded from the filesection. However there are a few caveats: =2D you'll have to apply a patch to make DW2 EH working =2D the scripts Danny publishes do require manual interaction =2D you are mote or less on your own Last not least you might want to check out http://www.mingw.org/MinGWiki/index.php/build a Win32 x-compiler for Linux While that page describes how to build a linux-hosted x-compiler it probably touches a couple of problems you will encounter as well. HTH, best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Stefan B. <sb...@sb...> - 2005-10-23 15:04:00
|
Michael Gerdau wrote: > > I need a MinGW g++ (based on 3.4) that is configured with sjlj > > exceptions disabled. Has anybody already built that configuration? > > If not, I'll have to build one myself. Is there anywhere > > documentation of how to build MinGW from the source and what is > > required to do so? > The script and options used by Danny to create the stock version > of MinGW g++ can be downloaded from the filesection. However there > are a few caveats: > - you'll have to apply a patch to make DW2 EH working Is this patch included in the source tarballs or do I have to search for it in the archive of this mailing list? > - the scripts Danny publishes do require manual interaction Manual interaction is no problem as long as there's good documentation. ;-) > - you are mote or less on your own Thanks, I'll have a look. > Last not least you might want to check out > http://www.mingw.org/MinGWiki/index.php/build a Win32 x-compiler for > Linux That page shows a "Fatal PhpWiki Error" for me. > While that page describes how to build a linux-hosted x-compiler > it probably touches a couple of problems you will encounter as well. In fact, I already successfully built a cross-compiler (from x86 GNU/Linux to x86 Windows) supporting C, C++ and Ada about one year ago (and posted patches here, IIRC, or at least to Debian). But this time I really need a native g++ compiler with sjlj disabled. :-} -- Stefan Bellon |
From: Michael G. <mg...@te...> - 2005-10-23 16:03:49
|
> Is this patch included in the source tarballs or do I have to search > for it in the archive of this mailing list? It can be found on the wikipage that give you the error. > Manual interaction is no problem as long as there's good documentation. > ;-) Well, that depends on what you consider "good documentation". It is scarcely documented at all. Either you know how to build gcc/mingw or you'll learn it along the way... > That page shows a "Fatal PhpWiki Error" for me. Strange -- I copied the URL directly from the addrbar and pasting it into Konqueror works here. Ok, here is another way: go to http://www.mingw.org/MinGWiki/index.php/FAQ Scroll down to "Cross Compiling" and click on How to "build a Win32 x-compiler for Linux" ? Or just got to the MinGWiki, FAQ, scroll down etc. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Stefan B. <sb...@sb...> - 2005-10-23 16:22:41
|
Michael Gerdau wrote: > > Is this patch included in the source tarballs or do I have to search > > for it in the archive of this mailing list? > It can be found on the wikipage that give you the error. Lucky me. :-} [snip] > > That page shows a "Fatal PhpWiki Error" for me. > Strange -- I copied the URL directly from the addrbar and pasting > it into Konqueror works here. > Ok, here is another way: > go to http://www.mingw.org/MinGWiki/index.php/FAQ > Scroll down to "Cross Compiling" and click on > How to "build a Win32 x-compiler for Linux" ? Gives the same "Fatal PhpWiki Error". I've now tried with two different browsers. And I've even turned off my local Privoxy because I suspected this to cause the trouble, but it doesn't show up if I turn off Privoxy either. Greetings, Stefan -- Stefan Bellon |
From: Eran <er...@be...> - 2005-10-23 18:45:24
|
Hi, I am running g++ (downloaded from the MinGW site) v3.4.4 and it looks like that the build process is quite slow. I am building Scintilla project using this compiler, however the build process seems 3 time slower then the build using VC7.1 or VC6!! I then checked in the task manager and it seems like that the g++ process takes max of ~40% CPU while the build process using MS compilers are always taking ~99% CPU. I tried to increase the process priority - didnt help. Any suggestions? Eran |
From: Stefan B. <sb...@sb...> - 2005-10-23 20:18:31
|
Michael Gerdau wrote: > Last not least you might want to check out > http://www.mingw.org/MinGWiki/index.php/build a Win32 x-compiler for > Linux Ok, using Firefox on Windows I was eventually able to see that page. Weird that Galeon on GNU/Linux and NetSurf on RISC OS are not able to display it but display a PhpWiki Error. Nevertheless ... I had again a closer look at the build script and extracted what seems necessary to build a native g++ on Windows (I don't need nor want a cross-compiler). Compilation of gcc-core and gcc-g++ seems to work ok for quite some time, but then I get the following error when Tcollect2.exe is being linked: gcc -O2 -fomit-frame-pointer -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -DHAVE_CONFIG_H -s -o Tcollect2.exe \ collect2.o tlink.o intl.o version.o ../libiberty/libiberty.a ../intl/libintl.a ../libiberty/libiberty.a(pexrd-unix.o)(.text+0x15):pexrd-unix.c: undefined reference to `pipe' ../libiberty/libiberty.a(pexrd-unix.o)(.text+0x61):pexrd-unix.c: undefined reference to `fork' ../libiberty/libiberty.a(pexrd-unix.o)(.text+0x224):pexrd-unix.c: undefined reference to `wait' ../libiberty/libiberty.a(pex-unix.o)(.text+0x77):pex-unix.c: undefined reference to `fork' ../libiberty/libiberty.a(pex-unix.o)(.text+0xde):pex-unix.c: undefined reference to `pipe' ../libiberty/libiberty.a(pex-unix.o)(.text+0x279):pex-unix.c: undefined reference to `wait' What did I do wrong? Am I missing some library? Or do I have to configure differently when compiling on Windows itself? -- Stefan Bellon |
From: Stefan B. <sb...@sb...> - 2005-10-23 21:55:27
|
Stefan Bellon wrote: > gcc -O2 -fomit-frame-pointer -DIN_GCC -DCROSS_COMPILE -W -Wall > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic > -Wno-long-long -DHAVE_CONFIG_H -s -o Tcollect2.exe \ > collect2.o tlink.o intl.o version.o ../libiberty/libiberty.a [snip] > What did I do wrong? Am I missing some library? Or do I have to > configure differently when compiling on Windows itself? Found out myself what went wrong. I was erroneously configuring with --enable-threads instead of --enable-threads=win32. This hurdle is taken. However later on I get another error during building of crtbegin.o and I'm not sure where this comes from: /home/sbellon/src/mingw/BUILD-gcc/gcc/xgcc -B/home/sbellon/src/mingw/BUILD-gcc/gcc/ -B/home/sbellon/mingw/pentium-mingw32msv/bin/ -B/home/sbellon/mingw/pentium-mingw32msv/lib/ -isystem /home/sbellon/mingw/pentium-mingw32msv/include -isystem /home/sbellon/mingw/pentium-mingw32msv/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc-3.4.4-20050522-1/gcc -I../../gcc-3.4.4-20050522-1/gcc/. -I../../gcc-3.4.4-20050522-1/gcc/../include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer \ -c ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o In file included from ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c:62: ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:79:19: stdio.h: No such file or directory ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:82:23: sys/types.h: No such file or directory ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:85:19: errno.h: No such file or directory ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:92:20: string.h: No such file or directory ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:93:20: stdlib.h: No such file or directory ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:94:20: unistd.h: No such file or directory In file included from ./include/syslimits.h:7, from ./include/limits.h:11, from ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:97, from ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c:62: ./include/limits.h:122:61: no include path in which to search for limits.h In file included from ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c:62: ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:100:18: time.h: No such file or directory In file included from ./tm.h:10, from ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c:64: ../../gcc-3.4.4-20050522-1/gcc/config/i386/cygming.h:358: error: syntax error before '*' token ../../gcc-3.4.4-20050522-1/gcc/config/i386/cygming.h:358: warning: function declaration isn't a prototype make[1]: *** [crtbegin.o] Error 1 What I don't understand is this: the "missing" files stdio.h, sys/types.h, errno.h, string.h, stdlib.h and unistd.h as well as time.h are all present in /home/sbellon/mingw/pentium-mingsw32msv/include which is a system include in the above call. So, what's wrong? Again, some mis-configuration? -- Stefan Bellon |
From: amores p. <lif...@ho...> - 2005-10-23 22:24:24
|
>Stefan Bellon wrote: ... > >However later on I get another error during building of crtbegin.o and >I'm not sure where this comes from: > >/home/sbellon/src/mingw/BUILD-gcc/gcc/xgcc >-B/home/sbellon/src/mingw/BUILD-gcc/gcc/ >-B/home/sbellon/mingw/pentium-mingw32msv/bin/ >-B/home/sbellon/mingw/pentium-mingw32msv/lib/ -isystem >/home/sbellon/mingw/pentium-mingw32msv/include -isystem >/home/sbellon/mingw/pentium-mingw32msv/sys-include -O2 -DIN_GCC -W >-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes >-Wold-style-definition -isystem ./include -I. -I. >-I../../gcc-3.4.4-20050522-1/gcc -I../../gcc-3.4.4-20050522-1/gcc/. >-I../../gcc-3.4.4-20050522-1/gcc/../include -g0 >-finhibit-size-directive -fno-inline-functions -fno-exceptions >-fno-zero-initialized-in-bss -fno-unit-at-a-time >-fno-omit-frame-pointer \ > -c ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c -DCRT_BEGIN \ > -o crtbegin.o >In file included from ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c:62: >../../gcc-3.4.4-20050522-1/gcc/tsystem.h:79:19: stdio.h: No such file >or directory >../../gcc-3.4.4-20050522-1/gcc/tsystem.h:82:23: sys/types.h: No such >file or directory >../../gcc-3.4.4-20050522-1/gcc/tsystem.h:85:19: errno.h: No such file >or directory >../../gcc-3.4.4-20050522-1/gcc/tsystem.h:92:20: string.h: No such file >or directory >../../gcc-3.4.4-20050522-1/gcc/tsystem.h:93:20: stdlib.h: No such file >or directory >../../gcc-3.4.4-20050522-1/gcc/tsystem.h:94:20: unistd.h: No such file >or directory >In file included from ./include/syslimits.h:7, > from ./include/limits.h:11, > from ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:97, > from ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c:62: >./include/limits.h:122:61: no include path in which to search for >limits.h >In file included from ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c:62: >../../gcc-3.4.4-20050522-1/gcc/tsystem.h:100:18: time.h: No such file >or directory >In file included from ./tm.h:10, > from ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c:64: >../../gcc-3.4.4-20050522-1/gcc/config/i386/cygming.h:358: error: syntax >error before '*' token >../../gcc-3.4.4-20050522-1/gcc/config/i386/cygming.h:358: warning: >function declaration isn't a prototype >make[1]: *** [crtbegin.o] Error 1 > >What I don't understand is this: the "missing" files stdio.h, >sys/types.h, errno.h, string.h, stdlib.h and unistd.h as well as time.h >are all present in /home/sbellon/mingw/pentium-mingsw32msv/include >which is a system include in the above call. > >So, what's wrong? Again, some mis-configuration? > >-- This is just me guessing, but it looks to me like you do not have this line -I/home/sbellon/mingw/pentium-mingsw32msv/include perhaps your -I./include is supposed to provide that, but perhaps the current directory is not what you expect, during the time that gcc processes ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c Cordially, Perry |
From: Stefan B. <sb...@sb...> - 2005-10-23 22:41:28
|
amores perros wrote: > >Stefan Bellon wrote: [snip] > >What I don't understand is this: the "missing" files stdio.h, > >sys/types.h, errno.h, string.h, stdlib.h and unistd.h as well as > >time.h are all present in > >/home/sbellon/mingw/pentium-mingsw32msv/include which is a system > >include in the above call. > > > >So, what's wrong? Again, some mis-configuration? > This is just me guessing, but it looks to me like you do not > have this line > -I/home/sbellon/mingw/pentium-mingsw32msv/include > perhaps your -I./include is supposed to provide that, > but perhaps the current directory is not what you expect, > during the time that gcc processes > ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c Yes, I thought about this as well and indeed I have even added exactly the include you mentioned above to the CRTSTUFF_CFLAGS variable in gcc/Makefile as a "temporary hack", but even this does not help. The effect is exactly the same. Therefore I'm not sure whether I'm missing some fundamental concepts of building a native MinGW. I'm a bit amazed that there are lots of instructions of how to build a MinGW cross-compiler, but there's little to be found about how to build a MinGW natively on Windows. In case somebody wonders, I have configured like this (from within ~/src/mingw/BUILD-gcc): ../gcc-3.4.4-20050522-1/configure --prefix=/home/sbellon/mingw --enable-languages=c,c++ --disable-nls --disable--checking --disable-libada --enable-threads=win32 --disable-sjlj-exceptions pentium-mingw32msv and then I try to build using this make call: make CFLAGS="-O2 -fomit-frame-pointer" CXXFLAGS="-mthreads -fno-omit-frame-pointer -O2" LDFLAGS=-s Does anybody spot something wrong with that? -- Stefan Bellon |
From: amores p. <lif...@ho...> - 2005-10-23 22:49:14
|
>Yes, I thought about this as well and indeed I have even added exactly >the include you mentioned above to the CRTSTUFF_CFLAGS variable in >gcc/Makefile as a "temporary hack", but even this does not help. The >effect is exactly the same. > But, if it doesn't come out on the gcc invocation line (and it didn't come out in the one you quoted), is that any use? (I'm not sure myself.) Cordially, Perry |
From: Stefan B. <sb...@sb...> - 2005-10-23 23:00:52
|
amores perros wrote: > >Yes, I thought about this as well and indeed I have even added > >exactly the include you mentioned above to the CRTSTUFF_CFLAGS > >variable in gcc/Makefile as a "temporary hack", but even this does > >not help. The effect is exactly the same. > But, if it doesn't come out on the gcc invocation line > (and it didn't come out in the one you quoted), > is that any use? (I'm not sure myself.) Oh, sorry, there's a misunderstanding. The lines I quoted where those from an unmodified Makefile. When this gave the mentioned error, I tried exactly what you suggested (i.e. adding the -I... to the Makefile). That include line then *did* appear but the effect was the same. I decided to post the output of the run with the unmodified Makefile as otherwise I could have broken it with my modifications. -- Stefan Bellon |
From: Michael G. <mg...@te...> - 2005-10-24 08:17:16
|
> Therefore I'm not sure whether I'm missing some fundamental concepts of > building a native MinGW. I'm a bit amazed that there are lots of > instructions of how to build a MinGW cross-compiler, but there's little > to be found about how to build a MinGW natively on Windows. Well, the Wiki only contains what users have provided. Apart from that I'm pretty sure almost all Windoze users are both used to and contend with using ready made binaries. It's mostly Unix/Linux folks that care about building from a source tarball at all. Anyway, once you've solved your problems you are free to add a page to the Wiki describing your findings. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Stefan B. <sb...@sb...> - 2005-10-24 07:03:56
|
Stefan Bellon wrote: > In file included from ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c:62: > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:79:19: stdio.h: No such file > or directory > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:82:23: sys/types.h: No such > file or directory > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:85:19: errno.h: No such file > or directory > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:92:20: string.h: No such file > or directory > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:93:20: stdlib.h: No such file > or directory > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:94:20: unistd.h: No such file > or directory [snip] > So, what's wrong? Again, some mis-configuration? Could these problems be there due to the fact that I'm trying to build MinGW from within a CygWin shell? Do I have to add another configure switch in that case? -- Stefan Bellon |
From: Brian D. <br...@de...> - 2005-10-24 08:01:09
|
Stefan Bellon wrote: > Could these problems be there due to the fact that I'm trying to build > MinGW from within a CygWin shell? Do I have to add another configure > switch in that case? If you build in Cygwin and don't specify --target then it will assume a native build (i686-pc-cygwin), which is probably not what you want. If you want to build a mingw hosted and targeted gcc from Cygwin you'd probably need explicit --target=mingw32 --host=mingw32. Brian |
From: Stefan B. <sb...@sb...> - 2005-10-24 09:58:54
|
Brian Dessent wrote: > Stefan Bellon wrote: > > > Could these problems be there due to the fact that I'm trying to build > > MinGW from within a CygWin shell? Do I have to add another configure > > switch in that case? > > If you build in Cygwin and don't specify --target then it will assume a > native build (i686-pc-cygwin), which is probably not what you want. If > you want to build a mingw hosted and targeted gcc from Cygwin you'd > probably need explicit --target=mingw32 --host=mingw32. In fact, I configured with: --build=i586-pc-mingw32 --host=i586-pc-mingw32 --target=i586-pc-mingw32 Is there something else? -- Stefan Bellon |
From: Brian D. <br...@de...> - 2005-10-24 10:28:20
|
Stefan Bellon wrote: > > If you build in Cygwin and don't specify --target then it will assume a > > native build (i686-pc-cygwin), which is probably not what you want. If > > you want to build a mingw hosted and targeted gcc from Cygwin you'd > > probably need explicit --target=mingw32 --host=mingw32. > > In fact, I configured with: > > --build=i586-pc-mingw32 --host=i586-pc-mingw32 --target=i586-pc-mingw32 Did you try with just --target=mingw32? That is how the mingw.org build scripts do it. Setting --build is probably a bad idea. You are actually building in i686-pc-cygwin if you run under cygwin. Most of the time you should let --build be detected. Also, if you're building from Cygwin then you're probably picking up Cygwin's gcc as $CC for the first part of the bootstrap, and that will be bad news -- unless for some reason you have a i586-pc-mingw32-gcc and friends in your path. But that's not likely unless you've done that by hand, because i586-pc-mingw32 is not a standard target triplet (and Cygwin doesn't provide the target-aliased versions of the commands anyway.) So you'll probably have to override it to use -mno-cygwin. It would probably be a whole lot simpler to do this from MSYS without any Cygwin binaries in the path. Brian |
From: Stefan B. <sb...@sb...> - 2005-10-24 17:17:05
|
Brian Dessent wrote: > Stefan Bellon wrote: > > In fact, I configured with: > > > > --build=i586-pc-mingw32 --host=i586-pc-mingw32 > > --target=i586-pc-mingw32 > > Did you try with just --target=mingw32? That is how the mingw.org > build > scripts do it. I now configured with: ../gcc-3.4.4-20050522-1/configure --prefix=/home/sbellon/mingw \ --enable-languages=c,c++ --disable-nls --disable-checking \ --disable-libada --enable-threads=win32 --disable-sjlj-exceptions \ --target=mingw32 And then I built with: make CFLAGS="-O2 -fomit-frame-pointer" \ CXXFLAGS="-mthreads -fno-omit-frame-pointer -O2" LDFLAGS=-s But then I get again this error: gcc -O2 -fomit-frame-pointer -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -DHAVE_CONFIG_H -s -o Tcollect2.exe \ collect2.o tlink.o intl.o version.o ../libiberty/libiberty.a ../libiberty/libiberty.a(pexrd-unix.o)(.text+0x15):pexrd-unix.c: undefined reference to `pipe' ../libiberty/libiberty.a(pexrd-unix.o)(.text+0x61):pexrd-unix.c: undefined reference to `fork' ../libiberty/libiberty.a(pexrd-unix.o)(.text+0x224):pexrd-unix.c: undefined reference to `wait' ../libiberty/libiberty.a(pex-unix.o)(.text+0x77):pex-unix.c: undefined referenceto `fork' ../libiberty/libiberty.a(pex-unix.o)(.text+0xde):pex-unix.c: undefined referenceto `pipe' ../libiberty/libiberty.a(pex-unix.o)(.text+0x279):pex-unix.c: undefined reference to `wait' make[1]: *** [collect2.exe] Error 1 make[1]: Leaving directory `/home/sbellon/src/mingw/BUILD-gcc/gcc' So it looks, that when I configure using just --target=mingw32, the --enable-threads=win32 is overridden again? > Setting --build is probably a bad idea. You are actually building in > i686-pc-cygwin if you run under cygwin. Most of the time you should > let > --build be detected. I want to build the g++ to match a particular gcc and gnat. Those have been built with the following configuration: --enable-languages=c,ada --disable-nls --disable-checking \ --disable-libada --enable-threads=win32 --disable-sjlj-exceptions \ pentium-mingw32msv It looks like the last part "pentium-mingw32msv" sets --build, --host and --target accordingly. When I configure like this: ../gcc-3.4.4-20050522-1/configure --prefix=/home/sbellon/mingw \ --enable-languages=c,c++ --disable-nls --disable-checking \ --disable-libada --enable-threads=win32 --disable-sjlj-exceptions \ pentium-mingw32msv Then I get much further: xgcc is built. But then, when using xgcc to compile things, it doesn't find its includes as it looks: /home/sbellon/src/mingw/BUILD-gcc/gcc/xgcc -B/home/sbellon/src/mingw/BUILD-gcc/gcc/ -B/home/sbellon/mingw/pentium-mingw32msv/bin/ -B/home/sbellon/mingw/pentium-mingw32msv/lib/ -isystem /home/sbellon/mingw/pentium-mingw32msv/include -isystem /home/sbellon/mingw/pentium-mingw32msv/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc-3.4.4-20050522-1/gcc -I../../gcc-3.4.4-20050522-1/gcc/. -I../../gcc-3.4.4-20050522-1/gcc/../include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer \ -c ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o In file included from ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c:62: ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:79:19: stdio.h: No such file or directory ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:82:23: sys/types.h: No such file or directory ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:85:19: errno.h: No such file or directory ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:92:20: string.h: No such file or directory ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:93:20: stdlib.h: No such file or directory ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:94:20: unistd.h: No such file or directory In file included from ./include/syslimits.h:7, from ./include/limits.h:11, from ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:97, from ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c:62: ./include/limits.h:122:61: no include path in which to search for limits.h In file included from ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c:62: ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:100:18: time.h: No such file or directory In file included from ./tm.h:10, from ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c:64: ../../gcc-3.4.4-20050522-1/gcc/config/i386/cygming.h:358: error: syntax error before '*' token ../../gcc-3.4.4-20050522-1/gcc/config/i386/cygming.h:358: warning: function declaration isn't a prototype make[1]: *** [crtbegin.o] Error 1 make[1]: Leaving directory `/home/sbellon/src/mingw/BUILD-gcc/gcc' Even if I replace the include lines in tsystem.h with _absolute_ paths to the actual files, it does not work. > Also, if you're building from Cygwin then you're probably picking up > Cygwin's gcc as $CC for the first part of the bootstrap, and that will > be bad news -- unless for some reason you have a i586-pc-mingw32-gcc > and > friends in your path. But that's not likely unless you've done that > by > hand, because i586-pc-mingw32 is not a standard target triplet (and > Cygwin doesn't provide the target-aliased versions of the commands > anyway.) So you'll probably have to override it to use -mno-cygwin. I haven't installed any GCC with CygWin. I just use it because of the shell, flex, bison, gettext and so on. And I have set the path to the MinGW GCC I use before all other CygWin paths in the PATH variable. > It would probably be a whole lot simpler to do this from MSYS without > any Cygwin binaries in the path. I tried this, but MSYS does not come with things I need like flex, bison, gettext, etc., does it? -- Stefan Bellon |
From: amores p. <lif...@ho...> - 2005-10-24 17:32:37
|
> > > It would probably be a whole lot simpler to do this from MSYS without > > any Cygwin binaries in the path. > >I tried this, but MSYS does not come with things I need like flex, >bison, gettext, etc., does it? > >-- >Stefan Bellon I think that is what mingw is for -- adding windows-native binaries like those, to a directory that you put in your path in your msys shell (but don't put them into the msys bin path, according to the msys docs, as there is something special about the msys bin directory I think). I'm only a newbie, so this is only a guess. Cordially, Perry |
From: Brian D. <br...@de...> - 2005-10-25 00:45:55
|
Stefan Bellon wrote: > > Did you try with just --target=mingw32? That is how the mingw.org > > build > > scripts do it. > > I now configured with: > > ../gcc-3.4.4-20050522-1/configure --prefix=/home/sbellon/mingw \ > --enable-languages=c,c++ --disable-nls --disable-checking \ > --disable-libada --enable-threads=win32 --disable-sjlj-exceptions \ > --target=mingw32 > > And then I built with: > > make CFLAGS="-O2 -fomit-frame-pointer" \ > CXXFLAGS="-mthreads -fno-omit-frame-pointer -O2" LDFLAGS=-s Sorry, I meant --target=mingw32 --host=mingw32, not just --target. (I was trying to say use mingw32 and not i586-pc-mingw32.) I say this because this is what the mingw.org build script does. > -Wno-long-long -DHAVE_CONFIG_H -s -o Tcollect2.exe \ > ... > So it looks, that when I configure using just --target=mingw32, the > --enable-threads=win32 is overridden again? Any time you see it building collect2, something is wrong, because collect2 is not supported for mingw. I think this is because there was no --host this time, so it was trying to build a "native" (meaning cygwin) hosted, mingw targeted gcc -- not what you want. > In file included from ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c:62: > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:79:19: stdio.h: No such file or directory > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:82:23: sys/types.h: No such file or directory > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:85:19: errno.h: No such file or directory > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:92:20: string.h: No such file or directory > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:93:20: stdlib.h: No such file or directory > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:94:20: unistd.h: No such file or directory I'm not sure what's going on here. > I haven't installed any GCC with CygWin. I just use it because of the > shell, flex, bison, gettext and so on. And I have set the path to the > MinGW GCC I use before all other CygWin paths in the PATH variable. The problem with building with cygwin is that config.guess will return i686-pc-cygwin, which is different from target and host, so it will think you are doing a cross-compilation which turns on all sorts of different behavior. You should be able to avoid this though by also overriding --build to be the same as --host and --target, but to me it seems like it would be more foolproof to just use MSYS. > I tried this, but MSYS does not come with things I need like flex, > bison, gettext, etc., does it? There's a MSYS bison package on mingw.org, but you should only need this if you modify a .y file. Flex should only be needed if you modify a .l file. If you aren't touching any of those neither should be necessary, assuming the timestamps are correct. You don't need gettext unless you include --enable-maintainer-mode to regenerate the .po files. But you're using --disable-nls so that's not even a concern. Brian |
From: Stefan B. <sb...@sb...> - 2005-10-25 06:36:04
|
Brian Dessent wrote: > Stefan Bellon wrote: > > ../gcc-3.4.4-20050522-1/configure --prefix=/home/sbellon/mingw \ > > --enable-languages=c,c++ --disable-nls --disable-checking \ > > --disable-libada --enable-threads=win32 \ > > --disable-sjlj-exceptions --target=mingw32 [snip] > Sorry, I meant --target=mingw32 --host=mingw32, not just --target. (I > was trying to say use mingw32 and not i586-pc-mingw32.) I say this > because this is what the mingw.org build script does. I tried that as well, but I always end up with: [snip] > > In file included from ../../gcc-3.4.4-20050522-1/gcc/crtstuff.c:62: > > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:79:19: stdio.h: No such file or directory > > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:82:23: sys/types.h: No such file or directory > > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:85:19: errno.h: No such file or directory > > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:92:20: string.h: No such file or directory > > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:93:20: stdlib.h: No such file or directory > > ../../gcc-3.4.4-20050522-1/gcc/tsystem.h:94:20: unistd.h: No such file or directory > I'm not sure what's going on here. Yes, somehow xgcc is not finding its includes. I think I may have missed applying a patch or something like that. -- Stefan Bellon |
From: Stefan B. <sb...@sb...> - 2005-10-24 10:00:15
|
Michael Gerdau wrote: > > Therefore I'm not sure whether I'm missing some fundamental concepts of > > building a native MinGW. I'm a bit amazed that there are lots of > > instructions of how to build a MinGW cross-compiler, but there's little > > to be found about how to build a MinGW natively on Windows. > > Well, the Wiki only contains what users have provided. That wasn't meant as criticism. I'm just surprised that apparently nobody has ever compiled a differently configured MinGW natively on Windows. > Apart from that I'm pretty sure almost all Windoze users are both > used to and contend with using ready made binaries. Yes, maybe. But I just _cannot_ use the default binary. I _have to_ use one with sjlj exceptions disabled. Sorry. :-( > Anyway, once you've solved your problems you are free to add > a page to the Wiki describing your findings. If I get that problem solved, I'm happy to provide instructions, yes. -- Stefan Bellon |
From: Luke D. <cod...@ho...> - 2005-10-25 14:26:39
|
----- Original Message ----- From: "Stefan Bellon" <sb...@sb...> To: <min...@li...> Sent: Monday, October 24, 2005 5:59 PM Subject: Re: [Mingw-users] Re: Need for a sjlj disabled g++ > Michael Gerdau wrote: >> > Therefore I'm not sure whether I'm missing some fundamental concepts of >> > building a native MinGW. I'm a bit amazed that there are lots of >> > instructions of how to build a MinGW cross-compiler, but there's little >> > to be found about how to build a MinGW natively on Windows. >> >> Well, the Wiki only contains what users have provided. > > That wasn't meant as criticism. I'm just surprised that apparently > nobody has ever compiled a differently configured MinGW natively on > Windows. > >> Apart from that I'm pretty sure almost all Windoze users are both >> used to and contend with using ready made binaries. > > Yes, maybe. But I just _cannot_ use the default binary. I _have to_ use > one with sjlj exceptions disabled. Sorry. :-( > >> Anyway, once you've solved your problems you are free to add >> a page to the Wiki describing your findings. > > If I get that problem solved, I'm happy to provide instructions, yes. > > -- > Stefan Bellon I've always thought it was necessary to extract the mingw-runtime and w32api packages into the install directory (the --prefix= directory) to eliminate the stdio.h errors, but I don't know if that is the "correct" way to build GCC. Luke |
From: Michael G. <mg...@te...> - 2005-10-25 14:49:15
|
> I've always thought it was necessary to extract the mingw-runtime and w32= api=20 > packages into the install directory (the --prefix=3D directory) to elimin= ate=20 > the stdio.h errors, but I don't know if that is the "correct" way to buil= d=20 > GCC. Now that you mention it: When building a Linux hosted MinGW x-compiler I do set PREFIX=3D<some path> TARGET=3Di586-mingw32 mkdir -vp $PREFIX/$TARGET/include tar xzf mingw-runtime-3.8-src.tar.gz cp -r mingw-runtime-*/include/* $PREFIX/$TARGET/include tar xzf w32api-3.3-src.tar.gz cp -r w32api-*/include/* $PREFIX/$TARGET/include and provide --prefix=3D$PREFIX --target=3D$TARGET to the gcc configure (and of course a few other things :) Then it works like a charm. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Stefan B. <sb...@sb...> - 2005-10-25 15:44:03
|
Michael Gerdau wrote: > Now that you mention it: > When building a Linux hosted MinGW x-compiler I do set > PREFIX=<some path> > TARGET=i586-mingw32 > > mkdir -vp $PREFIX/$TARGET/include > > tar xzf mingw-runtime-3.8-src.tar.gz > cp -r mingw-runtime-*/include/* $PREFIX/$TARGET/include > > tar xzf w32api-3.3-src.tar.gz > cp -r w32api-*/include/* $PREFIX/$TARGET/include That's what Danny's cross-compile script does (more or less) as well. I took that script as a guide when I tried it. > Then it works like a charm. I did this as well. In my first posting I mentioned (or at least I hope I did) that the files actually are present under the prefix (or was it the second posting?). Well, the files _are_ at the exact location that is given with -isystem to the xgcc. I think I even mentioned that even replacing #include <stdio.h> with #include "$PREFIX/$TARGET/include/stdio.h" does not work (i.e. giving a complete, absolute path to stdio.h). Therefore I think that the xgcc (or it's cpp?) which gets build in my case does not correctly handle includes. -- Stefan Bellon |