Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

wxWidgets 3.0 and Code::Blocks files question?

<< < (3/5) > >>

gd_on:
Hi,
I have not still tried your patches, but yesterday I have been able to build a working CodeBlocks on Windows 7 with wxWidgets 3.0.0.rc1, C::B svn 9392, everything compiled with TDM 4.8.1 distribution (32 bits).
To compile wxWidgets 3.0.0 I have made it as with wxWidgets 2.8 :

--- Code: ---mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-fno-keep-inline-dllexport" >log.txt 2>&1
--- End code ---
In the wiki, it is said than for a wxWidgets 2.9 version it's better to add "USE_STC=0 USE_PROPGRID=1", but it's not the case for 3.0 version : if you do that, the dll is not built because some scintilla components are missing.
To build C::B, I have used simply the _wx29 workspace as it is. I have just indicated C:\wxWidgets-3.0.0 in the environment wx29 variable and made a small add in C:\wxWidgets-3.0.0\lib : I copied in C:\wxWidgets-3.0.0\lib\gcc_dll, libwxmsw30u.a and libwxmsw30u_gl.a to libwxmsw29u.a and libwxmsw29u_gl.a respectively (just because in _wx29.cbps wxmsw29u is explicitely used, but they are effectively a 3.0 version). Of course, this is just for a test and stahta01 patches are certainly better than this workaround. Nevertheless, it works.

But, two remaining problems :
as with wxWidgets 2.9.5, there is still a warning concerning assert usage and I experienced one time only a crash, both probably caused by FortranProject plugin (I say that because the warning appears only when  FortranProject plugin is activated, and when I had the crash, in the .RPT file the name of this plugin appeared, but indirectly: not the main cause). The author of this plugin knows already this problem for wxWidgets 2.9.5 !

So, continue the good work. It's on the right way.

gd_on


[attachment deleted by admin]

Jenna:
Indeed, the crash/assert (shown in your screenshot) is caused by the Fortran-pluin's symbolbrowser, if I remembmer correctly.

gd_on:
Hi,
I have tried statha01 patches.
It's OK, but it's necessary to define the sub-globals variables WX_DEV.VERSION and WX_DEV.SUFFIX.
You can define them on the right part of the Global Variable Editor by entering "version" and "30" then "suffix" and "u" (without the quotes). Like that it's OK.

The problem I have seen, is that in a first try, I had not set those variables (I thought that C::B will ask them when needed, as it did for WX_DEV the first time!). C::B began to compile and after a while stopped because it said that wx/setup.h cannot be found in Platform.h. That's quite normal, because the path to this file was not correctly set.
But :
1) First thing: I had no messages telling me that WX_DEV.VERSION and/or WX_DEV.SUFFIX was not defined. May be not really easy to do, because there is another variable WX_DEV.CFG in the patches, not defined too, but which is finally (and must be) empty. (as WX_CFG in the different *_wx29.cbp)
2) The second thing is more annoying: After stopping on the line in Platform.h, telling me that wx/setup.h was missing, C::B hanged : no mouse reactions, even closing C::B by clicking the cross on the top of C::B window does not work the first time. If I insist, Windows show me a message indicating that C::B does not respond anymore and propose to kill the process. May be a bug somewhere in C::B ?
I tried this with several configurations of C::B (compiled with tdm 4.7.1, tdm 4.8.1 with the corresponding wxWidgets 2.8.12 configuration). It hanged in each configuration I tried.

gd_on

MortenMacFly:

--- Quote from: stahta01 on October 09, 2013, 04:02:57 am ---Edit: I had to undefine WX_PRECOMP and comment out including wx/wxprec.h to reduce the PCH size or prevent a bad header from erroring out cc1plus.exe under 4.8.1 and wxWidgets trunk.

--- End quote ---
Ah, that's interesting it seems you are talking about the same bug I reported in the GCC 4.8.1 announcement topic. I'll try your changes...

stahta01:

--- Quote from: MortenMacFly on October 12, 2013, 04:04:32 pm ---
--- Quote from: stahta01 on October 09, 2013, 04:02:57 am ---Edit: I had to undefine WX_PRECOMP and comment out including wx/wxprec.h to reduce the PCH size or prevent a bad header from erroring out cc1plus.exe under 4.8.1 and wxWidgets trunk.

--- End quote ---
Ah, that's interesting it seems you are talking about the same bug I reported in the GCC 4.8.1 announcement topic. I'll try your changes...

--- End quote ---

I am thinking its multiple headers that are causing the problem instead of size right now; but, I can not make a small sample to confirm this.

Tim S.

 

Navigation

[0] Message Index

[#] Next page

[*] Previous page