gcc4.7 can't build codeblocks

[reckless]

Been having some problems getting 4.7.0 stable on windows atleast good to hear it works on other architectures.
Sources that dont use libstdc++ work ok but those using libstdc++ crash with initialization error 0x000005.

[xunxun]

Been having some problems getting 4.7.0 stable on windows atleast good to hear it works on other architectures.
Sources that dont use libstdc++ work ok but those using libstdc++ crash with initialization error 0x000005.

It's strange.
Can you try -static linker option to make libstdc++ static link?
I haven't come across the problem.

[headkase]

Been having some problems getting 4.7.0 stable on windows atleast good to hear it works on other architectures.
Sources that dont use libstdc++ work ok but those using libstdc++ crash with initialization error 0x000005.

What compiler toolchain are you using on Windows?  I'm using this GCC 4.7.0:

Here

It comes in x86 and x86_64 flavors.  However, x86 will compile to x86_64 and vice-versa.  Which one you download therefore doesn't actually matter other than having one architecture the default.  Using this compiler toolchain on Windows: you have to manually point Code::Blocks at the toolchain executables - they aren't named as C::B expects them to be.

But, I'm not compiling C::B on Windows, I use the Nightlies there, - I'm just asking what toolchain you are using on Windows.

Edit: one thing to notice about those builds: there is no dwarf variant in the newest versions.  They are all sjlj variants.  That is because:

for windows OS, dwarf is a foreign way to implement the exceptions. It can not work correctly in windows because the implementation of С++ and C(SEH) exceptions in MSVC compiler uses SJLJ. Due to this fact, are introduced subtle bugs coming from the destruction of the stack and throwing/catching of exceptions between dll-modules.

[xunxun]

Edit: one thing to notice about those builds: there is no dwarf variant in the newest versions.  They are all sjlj variants.  That is because:

for windows OS, dwarf is a foreign way to implement the exceptions. It can not work correctly in windows because the implementation of С++ and C(SEH) exceptions in MSVC compiler uses SJLJ. Due to this fact, are introduced subtle bugs coming from the destruction of the stack and throwing/catching of exceptions between dll-modules.

mingw-build builds use multiple lib (32bit and 64bit), so he ( author is nixman ) must use sjlj to make gcc work.

In general, I like gcc with no multiple lib, so I build dw2 in win32 toolchain (official mingw also use dw2), and build sjlj in win64 toolchain.

[headkase]

mingw-build builds use multiple lib (32bit and 64bit), so he ( author is nixman ) must use sjlj to make gcc work.

In general, I like gcc with no multiple lib, so I build dw2 in win32 toolchain (official mingw also use dw2), and build sjlj in win64 toolchain.

I believe you.    That particular toolchain, the one I linked, is the one I'm using now although because the official MinGW (32 bit only), Here, only has GCC 4.6.2 as of this moment.  There is also a 64-bit MinGW: Here but I've never used that one - just have it bookmarked.  

[reckless]

Self compiled version used my previous working compiler (4.6.3) to bootstrap it.
I had a feeling something was of with my gcc build but i just tried one from mingw64 site and it also does it :S
Ill have a try with the one you posted. 

[reckless]

Ok tried with the version you posted and its the same 0xc000005 error  may i ask which version of wxwidgets you used ? was it 2.9.
I have a bad feeling that its wxwidgets crashing im using 2.8.11 and tried recompiling it with gcc-4.7.0 the built dll also crashes my working C::B so i guess somethings going totally fubar with wx 2.8.

[headkase]

Ok tried with the version you posted and its the same 0xc000005 error   may i ask which version of wxwidgets you used ? was it 2.9.
I have a bad feeling that its wxwidgets crashing im using 2.8.11 and tried recompiling it with gcc-4.7.0 the built dll also crashes my working C::B so i guess somethings going totally fubar with wx 2.8.

On my Arch Linux machine: my system-installed version of wxgtk is 2.8.12.

However, inside the C::B source-code folder there are folders for wx items such as wxscintella so I'm not sure where you are getting your wxwidgets from.

On Windows I'm using the prebuilt nightly and that includes a wx .dll file that you just drop into the nightly folder.

[reckless]

i ment specifically if trying to build codeblocks with gcc-4.7.0 on windows
example build codeblocks on windows with gcc-4.7.0 using a previously built wxwidgets (compiled with gcc-4.6.x) = crash.
rebuilding wxwidgets + codeblocks with gcc-4.7.0 on windows = crash.
so my thought was that the old 2.8 version of wxwidgets was somehow incompatible with gcc-4.7.0, strange thing it builds just fine but the dll does not work.
i checked it with depends to see if i was missing a dependency but all looks fine. debugging it turns out that it triggers a buffer overflow in malloc but no pointer to where.
this happens with all versions of gcc-4.7.0 even the latest from trunk so something is definatly fubar.

[headkase]

Have you tried to test the wxwidgets .dll on it's own with a minimal test program?  Compile the .dll, compile a small program that uses that dll and just opens a window, maybe makes a few buttons, and waits to close.  That's it.  Once you have wxwidgets working with that test program then try to try it with C::B?

Also, you don't have old wx .dll file(s) sitting in like your C:\Windows folder where they might override anything new you might compile do you?

I see on wxWidgets' download page that only source is provided for Windows so you'll have to compile it at any rate.

Also, your include folders (for .lib and .h, etc) are set up correctly for wx in your compilation environment?  The includes are not mis-matched, as in you aren't using a .h file from one version and attempting to use the corresponding .dll from another version with that .h file?

[reckless]

All setup according to wiki and still a nogo :/ no other wxwidgets dll's on system (depends can show the full path of loaded dll's)
Tried to start over completely but it still crashes. Weirdly enough cb_share_config.exe works but C::B itself crashes.

[headkase]

All setup according to wiki and still a nogo :/ no other wxwidgets dll's on system (depends can show the full path of loaded dll's)
Tried to start over completely but it still crashes. Weirdly enough cb_share_config.exe works but C::B itself crashes.

Yeah, sorry then.  I don't really know what to suggest, I was just trying to hit all the obvious ones..

[reckless]

Np all help welcome it might be a bug with gcc itself in that case ill report it to the gcc folks.

[xunxun]

Np all help welcome it might be a bug with gcc itself in that case ill report it to the gcc folks.

You can report to gcc bugzilla.
Jens don't allow us to discuss the problem here.

Let's return to gcc4.7 patch for cb discuss.

[stahta01]

Been having some problems getting 4.7.0 stable on windows atleast good to hear it works on other architectures.
Sources that dont use libstdc++ work ok but those using libstdc++ crash with initialization error 0x000005.

It's strange.
Can you try -static linker option to make libstdc++ static link?
I haven't come across the problem.

This nuwen.net build of 4.7 worked for me; I had to do the "-fpermissive" option.

NOTE: No minGW dll was used so, I guess it used static build.

Tim S.

http://nuwen.net/mingw.html