News:

The new Release 25.03 is out! You can download binaries for Windows and many major Linux distros here .

Main Menu

Patches for Compiling Code::Blocks against wxWidgets 3.0 using MinGW GCC 4.8.1

Started by stahta01, November 13, 2013, 04:07:03 PM

Previous topic - Next topic
Print
Go Down Pages1 2 All
User actions

stahta01

November 13, 2013, 04:07:03 PM Last Edit: January 03, 2014, 03:17:19 PM by stahta01
Moved my patches to here to compile Code::Blocks using wxWidgets 3.0 and TDM MinGW GCC 4.8.1

The reason for this group of patches  is because TDM's MinGW GCC version 4.8.1 crashes if PCH of sdk.h is used during building of Code::Blocks.
If the including of wxprec.h is stopped the crashing does NOT happen.
Crash message below.
Code Select

cc1plus.exe has stopped working.

More info on crash in wxForum thread http://forums.wxwidgets.org/viewtopic.php?f=19&t=38116



Edit:Removed two old patches.

Tim S.



C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]

oBFusCATed

#1
November 13, 2013, 04:20:29 PM
stahta01:
I'm totally lost in your patches and your topics (you have several of both).

Can I ask you to post an exact description what and why do you want to improve for every patch?
Also making a git branch based on mine or biplap's repo with all your commits in a proper order with proper
commit messages would be quite helpful and would increase the chance for your changes to get in SVN.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

stahta01

#2
November 13, 2013, 04:25:14 PM
Quote from: oBFusCATed on November 13, 2013, 04:20:29 PM
stahta01:
I'm totally lost in your patches and your topics (you have several of both).

Can I ask you to post an exact description what and why do you want to improve for every patch?
Also making a git branch based on mine or biplap's repo with all your commits in a proper order with proper
commit messages would be quite helpful and would increase the chance for your changes to get in SVN.


I just added some descriptions; do you need longer ones?
Or are they not clear enough?
Or need more reasons?

Do you think the wx/gauge.h should be included in sdk_common.h?
I am of two minds on what is best to do on that.

Tim S.
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]

killerbot

#3
November 13, 2013, 09:34:12 PM
suggestion : let us just stop using PCH's.

Compiling CB goes rather quickly (even without using pch's) and when one can use multi cores it goes amazingly fast.

Time after time, this is biting us. Let's try without and see where we end up ?

oBFusCATed

#4
November 13, 2013, 10:08:07 PM
Quote from: stahta01 on November 13, 2013, 04:25:14 PM
Do you think the wx/gauge.h should be included in sdk_common.h?
I don't know, what difference does it make?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

stahta01

#5
November 14, 2013, 12:58:29 AM
Quote from: oBFusCATed on November 13, 2013, 10:08:07 PM
Quote from: stahta01 on November 13, 2013, 04:25:14 PM
Do you think the wx/gauge.h should be included in sdk_common.h?
I don't know, what difference does it make?

If you use PCH correctly you need to fix the code so it compiles.
My patches work; if you wish to speed up compiling including a header only used once in the PCH wastes time and memory.
But, right now we are including all the headers inside wx/prec.h inside the SDK.h PCH.

Tim S.
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]

stahta01

#6
November 14, 2013, 03:29:12 AM
Quote from: killerbot on November 13, 2013, 09:34:12 PM
suggestion : let us just stop using PCH's.

Compiling CB goes rather quickly (even without using pch's) and when one can use multi cores it goes amazingly fast.

Time after time, this is biting us. Let's try without and see where we end up ?

I could try that route; I am nearly positive the 4.8.1 crash will go away.
Building of the Code::Blocks core project will likely be slower.
But, since the contrib projects already do NOT use the PCH version of sdk.h they should be no slower.
And, removing the flags doing precomp should speed up the building of the Contrib projects.

Will see if this solution works for 4.8.1 and see if it speeds up building CB Core project after I turn off the precomp flags.

Tim S.
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]

ollydbg

#7
December 30, 2013, 02:42:15 AM
FYI:

Hi, Tim and other guys, I just update a GCC bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926

I can reproduce the bug with a very simple test code (only MinGW compiler suite and boost header files are needed), so it looks like GCC can not read/handle big PCH files. See this Comment 6 with steps.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

#8
May 31, 2015, 10:27:08 AM
Nowadays, I'm trying to find the reason why the big pch will cause gcc crash. Now, I see that I may find the reason, the hard limited pch file size is around 128M, see my post in mingw-w64 forum for the information. [Mingw-w64-public] Set a larger pch file size limit? was : can anyone supply a debug version of cc1plus.exe?

Any one can build a new gcc tool chain which has larger hard coded value?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

stahta01

#9
May 31, 2015, 10:41:38 PM
Quote from: ollydbg on May 31, 2015, 10:27:08 AM
Nowadays, I'm trying to find the reason why the big pch will cause gcc crash. Now, I see that I may find the reason, the hard limited pch file size is around 128M, see my post in mingw-w64 forum for the information. [Mingw-w64-public] Set a larger pch file size limit? was : can anyone supply a debug version of cc1plus.exe?

Any one can build a new gcc tool chain which has larger hard coded value?

I have given up on finding the PCH build size issue cause.

But, I am now trying to cross build Code::Blocks under Debian Jessie using MinGW64 gcc for 32 bit build.
If I can duplicate the error under Debian Jessie, would that help you find the PCH bug?

Tim S.
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]

ollydbg

#10
June 01, 2015, 02:36:15 AM
Hi, Tim, I think the linux hosted gcc can handle big pch files quite well, so this can't help to solve the window hosted gcc issue. Thanks.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

#11
June 02, 2015, 07:32:37 AM
Good news, good news, the crash issue can be solved. See solutions in my Comment 17 in gcc bugzilla. Though I don't have the ability to build a gcc toolchain under windows, I can use the binary(hex) editor to modify the cc1plus.exe, and the result gcc don't crash when a 200M pch file is used.  :)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

oBFusCATed

#12
June 02, 2015, 08:27:12 AM
Probably you should talk to TDragon about this? :)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

ollydbg

#13
June 02, 2015, 08:52:10 AM
Quote from: oBFusCATed on June 02, 2015, 08:27:12 AM
Probably you should talk to TDragon about this? :)
I have posted those messages in mingw-w64 maillist, so I think John can see this, hope he can make new releases with those patch applied. :)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

#14
September 22, 2015, 11:52:35 PM Last Edit: September 22, 2015, 11:59:52 PM by ollydbg
Some good news: I recently see one gcc toolchain released which can handle big pch file without crash is mingw-build(from mingw-w64 site)
MinGW-w64 - for 32 and 64 bit Windows - Browse /Toolchains targetting Win32/Personal Builds/mingw-builds/5.2.0 at SourceForge.net

It include a patch 410-fix-using-large-pch.patch (Or the same one in mingw-build repo gcc-5.2-fix-mingw-pch.patch)

So, I can turn on the pch feature when building c::b against wx3.x, anyone knows a simple patch to enable pch on the windows C::B wx30 cbp file? Thanks.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.
Print
Go Up Pages1 2 All
User actions