From: Aaron G. <an...@be...> - 2007-11-21 15:06:33
|
Hello,=20 My names Aaron, and I am new to the MinGW Developers list. I am planning on trying to get Danny Smiths MinGW GCC 4.2.1 Port working = on Vista. If anyone else is interested in this, is working on this and/or has any = information that would be useful to this then please would you introduce = your self. AFAICT there is either a memory leak or a runtime system = incompatibility/ies or both introduced by Vista. GCC 3.4.5 on compiling Danny's MinGW gcc-4.2.1 grinds to a hault taking = hours to compile some of the gen*.c programs.=20 As the FSF say, "Bad Vista" ! Cheers, Aaron |
From: Kristian E. H. <kri...@gm...> - 2007-11-21 18:19:39
|
On Nov 21, 2007 10:06 AM, Aaron Gray <an...@be...> wrote: > As the FSF say, "Bad Vista" ! > > Cheers, > > Aaron > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr I thought the advertisement injection from Microsoft, immediately following a Vista bashing, was quite funny... <snip> > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ </snip> -- Kristian Erik Hermansen |
From: Aaron W. L. <aar...@aa...> - 2007-11-25 06:32:34
|
Aaron Gray wrote: > GCC 3.4.5 on compiling Danny's MinGW gcc-4.2.1 grinds to a hault taking > hours to compile some of the gen*.c programs. Can you be more specific about the nature of the halting? If it were to run out of memory due to memory leak, it should crash. Do you have some sort of working debugger? I don't have a copy of Vista, so unfortunately I can't help you directly. I'd need more information about the nature of the problems to give advice. If you just want to get things working, it might be easier to cross host from Linux, where you have a known-good working environment and a working debugger. That is, build=linux, host=mingw, target=mingw. But then again, it might not. Let us know how it goes. |
From: Brandon S. <br...@oq...> - 2007-11-29 03:14:09
|
On Nov 28, 2007, at 6:21 PM, Hin-Tak Leung wrote: > 3) gcc is useful enough, but what I am after is actually gfortran and > gcj - the former requires gmp which isn't bundled, and the latter > isn't > provided. would it is possible to put gmp together with the source > so that I > can cross-compile gfortran easier? > > 4) Does anybody use gcj on windows, and how good is the awt win32 > support? > (it is disabled in cross, but I'd like to know if native works > better...) I don't know if any of this is helpful to you, but this guy has a special interest in GCJ and MinGW. His page might be helpful to you unless you absolutely need to build it yourself. http://www.thisiscool.com/gcc_mingw.htm > > Lastly, has anybody been able to cross-build gcc 4.2.x at all? > (either from > linux, or more perversely, from cygwin) http://rpmfind.net/linux/RPM/sourceforge/m/mi/mingw-cross/mingw-gcc-gfortran-4.2.1-1.fc7.i386.html this RPM was posted on Oct 7, so it appears so. Brandon Sneed |
From: Hin-Tak L. <hin...@ya...> - 2007-11-29 12:21:01
|
Brandon Sneed wrote: > On Nov 28, 2007, at 6:21 PM, Hin-Tak Leung wrote: >> 3) gcc is useful enough, but what I am after is actually gfortran and >> gcj - the former requires gmp which isn't bundled, and the latter >> isn't >> provided. would it is possible to put gmp together with the source >> so that I >> can cross-compile gfortran easier? >> >> 4) Does anybody use gcj on windows, and how good is the awt win32 >> support? >> (it is disabled in cross, but I'd like to know if native works >> better...) > > > I don't know if any of this is helpful to you, but this guy has a > special interest in GCJ and MinGW. His page might be helpful to you > unless you absolutely need to build it yourself. > > http://www.thisiscool.com/gcc_mingw.htm Already know about this - that's the native gcj I tried under wine, BTW. (there is not official technical preview of gcj 4.2.* from the mingw team yet). (1) built executable generates have errors I cannot diagnose nor fix (2) the last release was almost a year ago; and the last intergrated swt release was 2-3 years ago... Well, I want to be able to build the 4.x cross-compiler reliably, not using a native one under wine, if I can help it... >> Lastly, has anybody been able to cross-build gcc 4.2.x at all? >> (either from >> linux, or more perversely, from cygwin) > > http://rpmfind.net/linux/RPM/sourceforge/m/mi/mingw-cross/mingw-gcc-gfortran-4.2.1-1.fc7.i386.html > > this RPM was posted on Oct 7, so it appears so. Thanks for this - I'll have a look... |
From: Hin-Tak L. <hin...@ya...> - 2007-11-30 17:25:14
|
Brandon Sneed wrote: <snipped> >> Lastly, has anybody been able to cross-build gcc 4.2.x at all? >> (either from >> linux, or more perversely, from cygwin) > > http://rpmfind.net/linux/RPM/sourceforge/m/mi/mingw-cross/mingw-gcc-gfortran-4.2.1-1.fc7.i386.html > > this RPM was posted on Oct 7, so it appears so. <snipped> Thanks for the tips - after downloading the source rpm and noted that the guy had essentially the same set up as I have (I am using fc8, actually), I realised a fundamental error of mine - I thought since I already have w32api/mingw-runtime/binutils/gcc-3.4.5 built via the cross script on sourceforge, I could just configure gcc-4.x to using the w32api/mingw-runtime/binutils there somehow (and have gcc 4.x installed in a different location and no overwriting gcc.3.4.x - this is possible with a native build of gcc on most platforms)... big mistake. It seems that the whole thing needs to be *bootstrapped together* for one destination directory. (look obvious in hidesight...). So in fact, the sourceforge cross script actually works, with 3 minor tips: 1) gcc-4.2.1-2.tar.gz is a single tar-ball whereas the script expects the source to be splitted into gcc-core/gcc-gcj/gcc-g++-<stuff>.tar.gz . The directory layout is the same for the sum total, and the script doesn't seems to care about extra files, so one just needs to copy/sym-link gcc-4.2.1-2.tar.gz to gcc-{core,g++,gcj}-4.2.1-2.tar.gz ... 2) gcc-4.2.1-2 seems to be quite inconsistent and expect some include files under ${INSTALL_DIR}/mingw/include occasionally, where as the installation actually put the includes in $INSTALL_DIR/include, so one needs to make such a sym-link in advance before the build in the destination directory. 3) binutils when used against gcc 4.2 also needs the --with-sysroot=$INSTALL_DIR option. One needs to put option BINUTILS_BASE_OPTIONS --with-sysroot=$INSTALL_DIR at the end of x86-mingw32-build.sh.conf After making these 3 adaptations, doing: sh ./x86-mingw32-build.sh --no-download --use-latest-versions --unattended just works. oh, a 4) gfortran needs libgmp (unlike g77) - so if gfortran-cross is desired, one needs to put libgmp under $INSTALL_DIR first. (a win32 binary is available on the mingw web site). I am driving the build by a small rpm spec wrapper around ./x86-mingw32-build.sh, so I know these are the *only* changes needed. |
From: Aaron G. <an...@be...> - 2007-11-25 12:13:28
|
Hello Aaron, Strange to have two Aaron's on the same list, its my birthday today :) Where I come from Aaron is not a very common name. > Aaron Gray wrote: > >> GCC 3.4.5 on compiling Danny's MinGW gcc-4.2.1 grinds to a hault taking >> hours to compile some of the gen*.c programs. > > Can you be more specific about the nature of the halting? It does not halt just gets slower and slower on the compiling the gen*.c programs. > If it were to run out of memory due to memory leak, it should crash. Right. > Do you have some sort of working debugger? gdb > I don't have a copy of Vista, so unfortunately I can't help you > directly. I'd need more information about the nature of the problems to > give advice. Okay, I will give you feedback as I get it. > If you just want to get things working, it might be easier to cross host > from Linux, where you have a known-good working environment and a > working debugger. That is, build=linux, host=mingw, target=mingw. But > then again, it might not. Yes I was thinking about working off of Cygwin. I do have a Linux machine too, so if Cygwin fails to produce useful results I will try that. > Let us know how it goes. Yes, thanks for the reply, Aaron |
From: Hin-Tak L. <hin...@ya...> - 2007-11-29 02:18:28
|
Aaron W. LaFramboise wrote: <snipped> > If you just want to get things working, it might be easier to cross host > from Linux, where you have a known-good working environment and a > working debugger. That is, build=linux, host=mingw, target=mingw. But > then again, it might not. > > Let us know how it goes. Actually I just spent a couple of days doing that cross with either the gcc 4.2.1-2 patched source or gcc 4.2.2 without success - so I resorted to running the win32 binaries under wine. It got stuck configuring libstdc++-3 saying linker cannot create executables (of course it cannot, I am trying to create a cross-compiler chain here) ; I tried both host=mingw target=mingw and host=linux target=mingw. One of them complains about compiling libiberty.a, the other about configuring libstdc++-3. FWIW, I built my own 3.4.5 cross with the mingw cross script and has upgraded a few times (for the runtime, w32api and binutils) and been using it for over a year now. So I have a few questions: 1) should I put the older 3.4.5 cross gcc in my $PATH ? ./configure seems to look for them and notice them if they are in my $PATH, but then many configure scripts contain redundant and not-used stuff. 2) I have the mingw-cross stuff under /opt/mingw/{bin,lib,include} , which contains the runtime, w32api, etc. I think for most part I need to do configure <options> --sysroot=/opt/mingw but some part of gcc 4.2.1/4.2.2 for some reasons look for includes under {$SYS_ROOT}/mingw/include rather than ${SYS_ROOT}/usr/include or ${SYS_ROOT}/include (either would do, since /opt/mingw/usr is a symlink pointing back to /opt/mingw). This looks to be a bug in gcc's source code, but I couldn't locate where. (I just make another symlink from /opt/mingw/mingw to /opt/mingw). 3) gcc is useful enough, but what I am after is actually gfortran and gcj - the former requires gmp which isn't bundled, and the latter isn't provided. would it is possible to put gmp together with the source so that I can cross-compile gfortran easier? 4) Does anybody use gcj on windows, and how good is the awt win32 support? (it is disabled in cross, but I'd like to know if native works better...) Lastly, has anybody been able to cross-build gcc 4.2.x at all? (either from linux, or more perversely, from cygwin) |
From: Mohan E. <gnu...@th...> - 2007-11-30 00:39:25
|
Hi All, >4) Does anybody use gcj on windows, and how good is the awt win32 support? >(it is disabled in cross, but I'd like to know if native works better...) AWT Win32 support is non-existent, aside from helper classes and anything that doesn't reply on native stuff (like peers). >Lastly, has anybody been able to cross-build gcc 4.2.x at all? (either from >linux, or more perversely, from cygwin) The page that Brandon mentioned: http://www.thisiscool.com/gcc_mingw.htm ...also has build scripts for 4.2 and an obsolete version of 4.3. These build scripts involve creating a cross compiler and then using that cross compiler to build a native one. If all you want is a cross compiler, you can stop halfway. -- Mohan http://www.thisiscool.com/ http://www.animalsong.org/ |
From: Hin-Tak L. <hin...@ya...> - 2007-11-30 17:18:17
|
Mohan Embar wrote: > Hi All, > >> 4) Does anybody use gcj on windows, and how good is the awt win32 support? >> (it is disabled in cross, but I'd like to know if native works better...) > > AWT Win32 support is non-existent, aside from helper classes and anything > that doesn't reply on native stuff (like peers). Thanks - I was wondering that - a particular GUI application works compiling to native on linux (which uses a GTK peer, I think) so I am wondering if I could just dump win32 GTK somewhere under mingw and build gcj with awt-enabled to make it work. >> Lastly, has anybody been able to cross-build gcc 4.2.x at all? (either from >> linux, or more perversely, from cygwin) > > The page that Brandon mentioned: > > http://www.thisiscool.com/gcc_mingw.htm > > ...also has build scripts for 4.2 and an obsolete version of 4.3. These build > scripts involve creating a cross compiler and then using that cross compiler > to build a native one. If all you want is a cross compiler, you can stop halfway. Oh, thanks. I didn't realised that was the approach you took... anyway, I found my problem now (separate post), and you probably want to know that your win32 binaries actually works under wine - although rather slowly, but I bet it is a wine fault. |
From: Mohan E. <gnu...@th...> - 2007-11-30 20:35:30
|
Hi Hin-Tak, >> AWT Win32 support is non-existent, aside from helper classes and anything >> that doesn't reply on native stuff (like peers). > >Thanks - I was wondering that - a particular GUI application works compiling to >native on linux (which uses a GTK peer, I think) so I am wondering if >I could just dump win32 GTK somewhere under mingw and build gcj with awt-enabled >to make it work. It's been theorized that this could work, but no one's ever tried it. I'm always skeptical about theoretical possibilities like this - the devil is in the details. If you try this and get it to work, please post your results. >>> Lastly, has anybody been able to cross-build gcc 4.2.x at all? (either from >>> linux, or more perversely, from cygwin) >> >> The page that Brandon mentioned: >> >> http://www.thisiscool.com/gcc_mingw.htm >> >> ...also has build scripts for 4.2 and an obsolete version of 4.3. These build >> scripts involve creating a cross compiler and then using that cross compiler >> to build a native one. If all you want is a cross compiler, you can stop halfway. > >Oh, thanks. I didn't realised that was the approach you took... anyway, I found >my problem now (separate post), and you probably want to know that your win32 >binaries actually works under wine - although rather slowly, but I bet it >is a wine fault. That's nice to know. The cross-compiler is much nicer to have, though. It runs much faster than even the native compiler on Win32. -- Mohan http://www.thisiscool.com/ http://www.animalsong.org/ |
From: Hin-Tak L. <hin...@ya...> - 2007-12-01 02:08:36
|
Hi Mohan, Mohan Embar wrote: <snipped> >>> AWT Win32 support is non-existent, aside from helper classes and anything >>> that doesn't reply on native stuff (like peers). >> Thanks - I was wondering that - a particular GUI application works compiling to >> native on linux (which uses a GTK peer, I think) so I am wondering if >> I could just dump win32 GTK somewhere under mingw and build gcj with awt-enabled >> to make it work. > > It's been theorized that this could work, but no one's ever tried it. > I'm always skeptical about theoretical possibilities like this - the > devil is in the details. If you try this and get it to work, please post > your results. I am surprised nobody has tried it - win32 GTK binary devel packages are quite readily available, so for a somewhat experienced native mingw user, just dumping the binary devel packages somewhere and run gcc's configure, etc, should either just work or have some problems that one can discuss about. (I myself don't get anywhere near a windows box at all, and mostly just insterested in supporting a windows build of something I write, without too much trouble on my side, so cross-compiling then testing quickly under wine is more interesting to me). I'll probably go that route soon - I need to do something similiar for libgmp and gfortran anyway. (currently my cross compiler suite consists of only gcc, g++ and gcj-without-awt). FWIW, the java application I was taking about is haploview (on sourceforge). I am registered as one of its developers although I have never done much, but I do have write access to the repository if change is required. built With your 4.0 under wine, it dies under genuine windows with: ----- Exception in thread "main" java.lang.NoClassDefFoundError: while resolving class ... Caused by: java.lang.ClassNotFoundException: javax.swing.JFrame not found in gnu .gcj.runtime.SystemClassLoader{urls=[file:C:\Program Files\QuickTime\QTSystem\QT Java.zip,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=n ull}} ----- built with your 4.3, it dies with: ------ Exception in thread "main" java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit at java.awt.Toolkit.getDefaultToolkit(Haploview-43.exe) ... Caused by: java.lang.ClassNotFoundException: gnu.java.awt.peer.gtk.GtkToolkit not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:C:\Program Files\QuickTim e\QTSystem\QTJava.zip], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} at java.net.URLClassLoader.findClass(Haploview-43.exe) ... ---------- I have tried converting all the java.awt and javax.swing imports to swingwt's, but there are about 6 unimplemented features (against gcj shipped with fedora 8) so it will not work with swt yet. <snipped> > That's nice to know. The cross-compiler is much nicer to have, though. It > runs much faster than even the native compiler on Win32. <snipped> Why is the cross-compiler quicker than the native? Just curious... One of the problems I have with the 4.2.1-2 official mingw tech-preview tarball and scripts, is that it contains at least 20 configure options - surely, building win32 gcc on win32 should *just work*? If it doesn't *just work* on a native MSYS build, it is a bug/deficiency with the configure script, and that needs to be fixed. Some nearby comments, to explain why say, BOOTCFLAGS="... -D__USE_MINGW_ACCESS" CFLAGS="... -D__USE_MINGW_ACCESS" is used; why one select '--enable-threads --disable-nls', etc? The difficulty with cross-building gcc 4.2.1 was because I had a mis-understanding: since I already have all of w32api/mingw-runtime/binutils with gcc 3.4.5, and I want to have 4.2.1 together with 3.4.5, I thought I could just run gcc's configure, point its configure in the direction of the gcc 3.4.5 bootstraps, tell it --target=mingw32, and have it just work. (it seems that one must build all of them under one roof - or together with binutils at least, I think -, but I am not sure I understand why). |
From: Mohan E. <gnu...@th...> - 2007-12-01 02:31:58
|
Hi Hin-Tak, >>>> AWT Win32 support is non-existent, aside from helper classes and anything >>>> that doesn't reply on native stuff (like peers). >>> Thanks - I was wondering that - a particular GUI application works compiling to >>> native on linux (which uses a GTK peer, I think) so I am wondering if >>> I could just dump win32 GTK somewhere under mingw and build gcj with awt-enabled >>> to make it work. >> >> It's been theorized that this could work, but no one's ever tried it. >> I'm always skeptical about theoretical possibilities like this - the >> devil is in the details. If you try this and get it to work, please post >> your results. > >I am surprised nobody has tried it - win32 GTK binary devel packages are quite >readily available, so for a somewhat experienced native mingw user, just dumping >the binary devel packages somewhere and run gcc's configure, etc, should either >just work or have some problems that one can discuss about.... Like I said, I've been tempted to do it at times, but too scared of the results. Plus SWT is fine enough for my purposes. >built With your 4.0 under wine, it dies under genuine windows with: >----- > Exception in thread "main" java.lang.NoClassDefFoundError: while resolving class >... >Caused by: java.lang.ClassNotFoundException: javax.swing.JFrame not found in gnu >.gcj.runtime.SystemClassLoader{urls=[file:C:\Program Files\QuickTime\QTSystem\QT >Java.zip,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=n >ull}} I think in my 4.0 build, I remove all of the Swing and AWT classes since they are useless anyway. >built with your 4.3, it dies with: >------ >Exception in thread "main" java.awt.AWTError: Cannot load AWT toolkit: >gnu.java.awt.peer.gtk.GtkToolkit > at java.awt.Toolkit.getDefaultToolkit(Haploview-43.exe) >... >Caused by: java.lang.ClassNotFoundException: gnu.java.awt.peer.gtk.GtkToolkit >not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:C:\Program Files\QuickTim >e\QTSystem\QTJava.zip], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], >parent=null}} > at java.net.URLClassLoader.findClass(Haploview-43.exe) In 4.3, I stopped removing the Swing and AWT classes by hand because it was too labor-intensive to get things to work. ><snipped> >> That's nice to know. The cross-compiler is much nicer to have, though. It >> runs much faster than even the native compiler on Win32. ><snipped> > >Why is the cross-compiler quicker than the native? Just curious... Actually, I should probably qualify that make and bash are slower and so building any non-trivial application is slower. Not sure if the actual compiler itself is slower. Sorry for the misinformation. >One of the problems I have with the 4.2.1-2 official mingw tech-preview tarball >and scripts, is that it contains at least 20 configure options - surely, >building win32 gcc on win32 should *just work*? If it doesn't *just work* >on a native MSYS build, it is a bug/deficiency with the configure script, and >that needs to be fixed. Some nearby comments, to explain why say, > >BOOTCFLAGS="... -D__USE_MINGW_ACCESS" CFLAGS="... -D__USE_MINGW_ACCESS" > >is used; why one select '--enable-threads --disable-nls', etc? Some of these options are probably unnecessary. I inherited the build scripts from Ranjit Mathew and tweaked them occasionally as necessary without questioning them too much. >The difficulty with cross-building gcc 4.2.1 was because I had a >mis-understanding: since I already have all of w32api/mingw-runtime/binutils >with gcc 3.4.5, and I want to have 4.2.1 together with 3.4.5, I thought >I could just run gcc's configure, point its configure in the direction of the >gcc 3.4.5 bootstraps, tell it --target=mingw32, and have it just work. (it seems >that one must build all of them under one roof - or together with binutils at >least, I think -, but I am not sure I understand why). Ranjit has a good article here: http://rmathew.com/articles/gcj/bldgcj.html Unfortunately, the site seems down. If you paste the above URL in Google, you can view the article in Google's cache. -- Mohan http://www.thisiscool.com/ http://www.animalsong.org/ |
From: Hin-Tak L. <hin...@ya...> - 2007-12-01 04:59:31
|
Mohan Embar wrote: <snipped> > Like I said, I've been tempted to do it at times, but too scared of the results. > Plus SWT is fine enough for my purposes. I'd like to try it one day - since the strength of the java platform is very much to do with the GUI. Writing 'Hello World' console applications is fine and good, but I don't know anybody who wants to limit themselves that way. <snipped> > I think in my 4.0 build, I remove all of the Swing and AWT classes since they are > useless anyway. <snipped> > In 4.3, I stopped removing the Swing and AWT classes by hand because it was too > labor-intensive to get things to work. I wanted to cross-compile gcj 4.x lately, mostly because gcj on linux (fedora 8) is clearly useable with all the swing/awt bells and whistles. <snipped> > Actually, I should probably qualify that make and bash are slower and so > building any non-trivial application is slower. Not sure if the actual compiler > itself is slower. Sorry for the misinformation. <snipped> From my experience - converting haploview's jar file to native win32 (although it doesn't work), make and bash doesn't feature since there is no(?) shell sub-processes involved. win32 gcc under wine takes about maybe twice to 3 times as long compared to cross gcc. I think most of the difference is wine's overhead. <snipped> > Ranjit has a good article here: > > http://rmathew.com/articles/gcj/bldgcj.html > > Unfortunately, the site seems down. If you paste the above URL in Google, > you can view the article in Google's cache. <snipped> Thanks for the pointer! Hin-Tak |