GCC 4.2.1 binary release for mingw is available.
You can download it from:
https://sourceforge.net/project/showfiles.php?group_id=2435
The binaries are archived by language.
There are two versions, differing in the model used for exception unwind info.
(1) Setjump-longjump (sjlj). Historically,and currenetly, the default model.
(2) Dwarf2 table-based unwinding (dw2). The more efficient model.
*This is built with Dwarf 2 unwind info enabled. The gcc, g++ and
gfortran drivers in the bin directory have a '-dw2' suffix to indicate
that, You can remove '-dw2; from these files if you like.
If you want sjlj you will find them (soon) in the gcc-4.2.1-sjlj-1 package
The binaries were compiled with --enable-version-specific-runtime-libs.
The runtime libs are in <mingw-root>/lib/gcc/mingw32/gcc-4.2.1-dw2. Do
not move these files. If you really must, don't bother reporting
installation bugs.
allright, this weekend I will try to build CB with it on windows. In case all seems fine, I might kick out a nightly with this. Could it be, at last, bye bye GCC 3.4.x ;-)
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp/ccNY169T.s: Assembler messages:
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp/ccNY169T.s:1448: Error: invalid character '_' in mnemonic
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp/ccNY169T.s:1465: Warning: .def pseudo-op used inside of .def/.endef: ignored.
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp/ccNY169T.s:1465: Error: junk at end of line, first unrecognized character is `_'
mingw32-make: *** [gcc_mswuddll\monodll_archive.o] Error 1
allright, this weekend I will try to build CB with it on windows. In case all seems fine, I might kick out a nightly with this. Could it be, at last, bye bye GCC 3.4.x ;-)Tried already, would have been too good if it worked. :(
BTW: If you use the MinGW installer you will get mingw-runtime-3.13.tar.gz instead of mingw-runtime-3.12.tar.gz which is officially announced. Might be that this is related... or not... don't know as I'm ill and have to stay in bed. :(
BTW: If you use the MinGW installer you will get mingw-runtime-3.13.tar.gz instead of mingw-runtime-3.12.tar.gz which is officially announced. Might be that this is related... or not... don't know as I'm ill and have to stay in bed. :(
mingw-runtime-3.13 and win32-api-3.10 has been released couple of days back. They are someway related to the latest gcc release.
Get well soon. :)
* libstdc++ and libgfortran require version 3.13 of mingw-runtime and
w32api version 2.2 or higher.
* This package does _not_ contain binutils, the mingw-runtime
or the w32api. You will need to get these if you do not already
have mingw installed.
* libstdc++ and libgfortran require version 3.13 of mingw-runtime and
w32api version 2.2 or higher. Yes, I've said it twice now.
* Static and dll libraries of libgcc and libstdc++ are in the release.
By default, linkage is to static libraries. More details later.
* OpenMP is enabled. To use it you will need to have win32-pthreads package
installed. More details later.
* Static and dll libraries of libgcc and libstdc++ are in the release.Has anybody found a shared version (dll) of libgcc?
By default, linkage is to static libraries. More details later.
Quote* Static and dll libraries of libgcc and libstdc++ are in the release.Has anybody found a shared version (dll) of libgcc?
By default, linkage is to static libraries. More details later.
First, the wxWidgets headers gernerate a thousand warnings (which is not so severe), and then it fails with
{standard input}:14784: Error: invalid character '_' in mnemonic
{standard input}:14801: Warning: .def pseudo-op used inside of .def/.endef: ignored.
{standard input}:14801: Error: junk at end of line, first unrecognized character is `_'
...whatever it means. No hint as to what source file the error refers to.
Wow finally they did it. But TD can you tell us what took them so long? And when can we expect the next full MingW release?I can tell you - they were ready to issue the binaries, but not ready to support the release since they were still too busy on the prior release. Someone stepped in and offered to help support the release - so they released it.
No, I do have libstdc++ DLLMe too. But it depends on a shared libgcc, which I do not find.
Wow finally they did it. But TD can you tell us what took them so long? And when can we expect the next full MingW release?My answer to why it took so long would be to quote Greg Chicares from the MinGW lists:
If you wait to release until the software becomes stable, then it might be later than you'd like. If you opt to release earlier, then it might be less stable than you'd like. There are some people who choose a less-conservative tradeoff than the MinGW project; ...and Keith Marshall:
We have one individual, (Danny), who is willing to manage GCC releases; he takes a cautious approach to that, for reasons which only he can definitively explain.The next release? Probably shortly after GCC 4.3.0 is released (which will be labeled 4.4.0 if GCC goes ahead with their totally weird GPLv3 rebranding scheme).
I can tell you - they were ready to issue the binaries, but not ready to support the release since they were still too busy on the prior release. Someone stepped in and offered to help support the release - so they released it.I wasn't aware of anything like this; I wonder who it was?
no include in the root mingw directoryYou forgot to do BinUtils and Runtime.
why they use a wired lib\gcc\mingw32\4.2.1-sjlj\include\c++ include directory?
compiling Code::Blocks gives about 2000 warnings (almost all of them from wxWidgets)
It's mostly about WXDLLEXPORT, WXDLLIMPEXP, WXDLLIMPEXP_SCI, and WXDLLIMPEXP_PG.
I have no idea what we need them for, anyway (or if at all?). Since we don't do any dynamic loading, I think those should be not needed at all? The linker should figure out a symbol if it's not exported, too... shouldn't it?
Anyway, that's what triggers the "attribute blah blah cannot blah" style error.
Having a problem getting version 4.2.1 working! (Strictly a mingw/gcc problem, not a CodeBlocks problem but...)
When I try to invoke the compiler (from the command line or from C::B), I get a message:
"mingw32-g++.exe: CreateProcess: No such file or directory"
Here I've renamed the .exe by removing the "-dw2" bits but it makes no difference leaving the "-dw2" naming as is - same error. Flipping the toolchain back to 3.4.5, the thing runs fine with no changes.
Since you guys seem to have got it working OK, any suggestions welcome.
BTW: WinXP-SP2
Try changing the file name in C::B compiler settings
Under tab "Toolchain Executables" I have
C Compiler: mingw32-gcc.exe
C++ Compiler: mingw32-g++.exe
Linker for Dyn Libs: mingw32-g++.exe
Do you have the C++ compiler installed at all? This sounds like a stupid question, but it can actually happen.
gcc (or mingw-gcc) is no compiler, you know. It is only a frontend to about half a dozen different compilers that all work via one common interface, and g++ being one of these compilers.
If gcc complains that there is no such file as mingw32-g++.exe, this suggests that you have downloaded the base package, but not the C++ package (or, it could be that paths are set up badly).
Interesting. But building wxWidgets invokes the compiler from the command line via make. Have you managed to build anything by spawning 4.2.1 from within CodeBlocks? Like "Hello world", for example? It would be helpful to know if someone else can do this without problems.Of coarse. I build all my projects with MinGW 4.2.1. It works fine in Code::Blocks and make.
Then you need to change the three directories under 'Settings->Compiler and Debugger...->Search Directories->Compiler', 'Settings->Compiler and Debugger...->Search Directories->Linker', and 'Settings->Compiler and Debugger...->Search Directories->Resource Compiler' to match your installation of MinGW (e.g. 'C:\MinGW4\include).
...
Also, does anyone know if the dw2 version is safe on win32? Everyone seems to be using it but I thought that dw2 couldn't unwind foreign frames and so couldn't handle exceptions in the OS or callbacks. Are they just betting that exceptions won't occur or has something changed?
It is working great for me. Actually it fixes a bug in the 3.4.5 sjlj model. It now can properly catch an exception passing the Compiled as C throwing to my C++ main program barrier (I don't know if there is a technical term for that :) ). The exceptions seem to be working as good as Visual C++. I have compiled and use wxWidgets 2.8.4 with it as well.
Thanks for the good report! Are you referring to throwing an exception from within (or below) WndProc and catching it in WinMain? My understanding is that since WndProc is a callback, there are OS frames between WndProc and WinMain which dw2 cannot unwind, but perhaps this has been fixed.Is there a specific test I can run to help you out? I have released a simple installer that can live side by side with MinGW v3.x.x. You can easily uninstall it after you are done. It doesn't set any environment variables or things like that. If you would like you can find it here (http://wxpack.sf.net/Main/Downloads) (MinGW Gcc v4.2.1 Unofficial Installer at the bottom of the downloads page).
Is there a specific test I can run to help you out?
Well I am referring to C++ and Lua. In Lua when you have an error, the error needs to propagate from _longjmp/_setjmp. This completely did not work in 3.4.5. I don't know the technical terms for crossing the 'C' code to 'C++' code barrier, but that is what seemed to be fixed.
That's very kind of you to offer, but after constructing a simple test, it wasn't too difficult to build it myself. I attached the source to this post in case you're curious.I will try. I really hope this is fixed.
Left click in the client area to throw an exception from WndProc that should be caught in WinMain. Right click just tests that exceptions work.
Unfortunately, based upon that test, dw2 does not function properly: an exception cannot propagate through foreign (OS) frames -- instead it terminates. It appears to work fine with 4.2.1-sjlj.
...Yes I build both with the same compiler.
That's interesting. I imagine that would also be fixed in 4.2.1-sjlj. Did you build both your app and Lua with gcc-4.2.1-dw2?
btw, wxPack looks to be very useful. Thanks! :)Thanks.
Does anyone know how i can enable OpenMP-Support in the official MinGW release?First, you need to build pthreads-win32 (the standard DLL -- "make GC-inlined"); second, you need to add "-fopenmp" and the path to the DLL (typically "pthreadGC2.dll") to your command line.
[100.0%] g++.exe -LC:\mSYS\local\lib -LC:\mSYS\local\lib\boost-1.34.1\lib -LC:\MinGW\lib\gcc\mingw32\4.2.1-dw2 -LC:\MinGW\lib -o bin\Release\DisplayOPENGL.exe obj\Release\Main.o -s -L/usr/local/lib -mthreads -Wl,--subsystem,windows -mwindows -lwx_msw_aui-2.8 -lwx_msw_xrc-2.8 -lwx_msw_qa-2.8 -lwx_msw_html-2.8 -lwx_msw_adv-2.8 -lwx_msw_core-2.8 -lwx_base_xml-2.8 -lwx_base_net-2.8 -lwx_base-2.8 -lwx_msw_richtext-2.8 -lMagick++ -lWand -lMagick -lgdi32 -lm -lpthreadGC2 -lSDLFor your example why do you link against:
Why is that here? I can not remember it. But I do not worry! I do not need it!
I guess you tried to use a wxWidgets project to compile your console app.Possibly - yes. But this would still make me wonder where all those references to SDL, pthread and "whatever" libs are comping from. Strange enough.