GCC 4.2.1 binary release for mingw is available from MINGW

[wxLearner]

No, I do have libstdc++ DLL

Me too. But it depends on a shared libgcc, which I do not find.

I have tried to throw an exception from a dll and catch it in an exe, but it does not work any longer with a statically linked runtime.

[TDragon]

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?

[snija]

Somebody can tell me why there`s no include in the root mingw directory and why they use a wired lib\gcc\mingw32\4.2.1-sjlj\include\c++ include directory?

[stahta01]

no include in the root mingw directory

You forgot to do BinUtils and Runtime.

why they use a wired lib\gcc\mingw32\4.2.1-sjlj\include\c++ include directory?

Because that is the way MinGW does it; it is in order to do more than one version of GCC in a top level MInGW folder, but I don't try to do that. So, I have no idea how or if it works well.

Tim S

[snija]

Thanks, I used to install binutils and w32api in separated folders and add their path into environment variables (C_INCLUDE_PATH & CPLUS_INCLUDE_PATH & LIBRARY_PATH).
If they use it in that way which means that you must unpacked it to c:\ otherwise .....
ignoring nonexistent directory "/mingw/lib/gcc/mingw32/4.2.1-dw2/include/c++"
ignoring nonexistent directory "/mingw/lib/gcc/mingw32/4.2.1-dw2/include/c++/min
gw32"
ignoring nonexistent directory "/mingw/lib/gcc/mingw32/4.2.1-dw2/include/c++/bac
kward"
ignoring nonexistent directory "/mingw/include"
I have to follow it and create a wired include directory "\include\c++\4.2.1-sjlj".
BTW, who actually find that libgcc_s_****.dll?

[dwmcqueen]

There has been a new release that supposedly fixed some of the bugs people were noticing from MinGW.

[killerbot]

thanks for the info !!!

EDIT : trying to build wx284, with the dwarf (DW2) variant, in bin dir I removed the -dw2 from the gcc exes (not from the mingw32-*.exe)

EDIT2 : failed -> windres ...... on ../../src/msw/version.rc:12:24 error: wx/version.h : no such file or directory  :-(

[thomas]

mingw32-g++-dw2.exe -Ldevel -Lsrc\wxAUI -Lbase\tinyxml -LD:\wxMSW-2.8.4\lib\gcc_dll -LC:\gcc42\lib  -o devel\codeblocks.exe .objs\src\app.o .objs\src\appglobals.o .objs\src\associations.o .objs\src\compilersettingsdlg.o .objs\src\crashhandler.o .objs\src\dlgabout.o .objs\src\dlgaboutplugin.o .objs\src\environmentsettingsdlg.o .objs\src\infopane.o .objs\src\ipc.o .objs\src\main.o .objs\src\printdlg.o .objs\src\scriptconsole.o .objs\src\scriptingsettingsdlg.o .objs\src\splashscreen.o .objs\src\startherepage.o  .objs\src\resources\resources.res  --demangle  -lcodeblocks -lwxaui -lwxscintilla -lshfolder -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lcomctl32 -lodbc32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lwxmsw28u  -mwindows
.objs\src\app.o: In function `wxMemoryFSHandler':
Info: resolving SquirrelVM::_VM       by linking to __imp___ZN10SquirrelVM3_VME (auto-import)
D:/wxMSW-2.8.4/include/wx/fs_mem.h:60: undefined reference to `_imp___ZTV17wxMemoryFSHandler'
collect2: ld returned 1 exit status
Process terminated with status 1 (8 minutes, 37 seconds)
1 errors, 1996 warnings

Yay for MinGW! Compiling Code::Blocks works again


EDIT:  The linker error is no real error, since I've used the 3.4.5 libraries, this obviously cannot work. But most importantly, the compilation is just fine   Now off to rebuild wxWidgets...

[thomas]

There goes!

[killerbot]

did you use the dwarf or the other ? Since I got stuck at wx :-(

EDIT : it seems it has to do with windres.exe, I used the latest snapshot of binutils [remember the one where the fix is there for windres.exe for files/paths containing spaces], well it seems it has new problems now.
So I replaced the windres.exe with the one from the previous release of the binutils and I can get past my error point ...

Fix one, break one, so it seems ...

EDIT2 : I heard a MinGW developer visits our forum, I hope you see this ;-)

[thomas]

I used the Dwarf2 version with the whatever-version-binutils that I'm using with my 3.4.5.

First, I edited CC and CPP in build/msw/config.gcc as this should actually be the correct way. Of course it didn't work... lol... now thinking about it, I didn't honestly expect it to work either, that would have been the first painless wxWidgets build

But seriously, as this failed, I just renamed the -dw2.exe files, and it worked nicely. Compiling wxWidgets gives about 300,000 compiler warnings, as usual, but hey... compiling Code::Blocks gives about 2000 warnings (almost all of them from wxWidgets). But hey, it works great otherwise

[killerbot]

compiling Code::Blocks gives about 2000 warnings (almost all of them from wxWidgets)

f***, holy crap, I hope those wx guys will do something about their warnings some day.

[thomas]

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.

[dwmcqueen]

So our the nightly builds going to move to 4.2.1 anytime soon

[insert_coin()]

Maybe it is not the correct place for this question, but does anyone know how to link mingwm10.dll statically?