Author Topic: Patches for Compiling Code::Blocks against wxWidgets 3.0 using MinGW GCC 4.8.1  (Read 14457 times)

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6678
    • My Best Post
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.



« Last Edit: January 03, 2014, 03:17:19 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12129
    • Travis build status
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!]

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6678
    • My Best Post
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++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5195
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 ?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12129
    • Travis build status
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!]

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6678
    • My Best Post
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++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6678
    • My Best Post
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++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
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.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
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.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6678
    • My Best Post
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++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
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.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12129
    • Travis build status
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!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
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.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
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.
« Last Edit: September 22, 2015, 11:59:52 pm by ollydbg »
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.