wxWidgets 3.0.0 released!

[ollydbg]

From http://www.wxwidgets.org/

New Stable Major wxWidgets 3.0.0 Release
2013-11-11

The final version of wxWidgets 3.0, the first new stable wxWidgets release in years and the first new major release since 1998, is now available. Please download the sources and binaries for the selected Windows compilers (Microsoft Visual C++ and MinGW-TDM) from SourceForge or our FTP mirror. As usual, the release files contain the sources and the documentation for the library in Unix (.tar.bz2) and Windows (.zip or .7z, with the latter being significantly smaller) formats. Notice that the documentation is also available online.

3.0 release is a culmination of several years of work since 2.8 and so brings many important improvements compared to the old stable series, such as much better and simpler to use support for Unicode, the new wxOSX/Cocoa port, suitable for development of 64 bit GUI applications under OS X, and support for GTK+ 3 in wxGTK port, as well as a huge number of other new features and bug fixes which are too numerous to be listed here, so please refer to the change log for the full list. And if you're upgrading from a previous version, please pay special attention to the "incompatible changes" section of this file and the changes chapter of the manual for even more details.

We hope you will enjoy using the latest and greatest version of wxWidgets! And if not, there is always the possibility to report bugs in it on our bug tracker. Have fun and good luck!

Also some binaries files include binaries files build from TDM4.7.1 and TDM4.8.1, both 32bit and 64bit, debug version and release version which are contributed by our forum user: Xaviou.

See: https://sourceforge.net/projects/wxwindows/files/3.0.0/binaries/

[Alpha]

Yes!  It is out!

(Do we yet have a recommended set of configure flags when building wx30 to build Code::Blocks against?)

[oBFusCATed]

(Do we yet have a recommended set of configure flags when building wx30 to build Code::Blocks against?)

We don't recommend it, building C::B against wx30 is only for people who like to port C::B to wx30...

[ptDev]

At the very least, the wxWidgets project wizard should be updated.

[oBFusCATed]

At the very least, the wxWidgets project wizard should be updated.

There is a patch provided here: http://forums.codeblocks.org/index.php/topic,18460.0.html
It would be good if interested people test it and report if it is working or not...

[Alpha]

(Do we yet have a recommended set of configure flags when building wx30 to build Code::Blocks against?)

We don't recommend it, building C::B against wx30 is only for people who like to port C::B to wx30...

Well, working on porting was my intent.
(From what I can tell Code::Blocks expects wxWidgets to be multi-lib under Linux.)

[Jenna]

(Do we yet have a recommended set of configure flags when building wx30 to build Code::Blocks against?)

We don't recommend it, building C::B against wx30 is only for people who like to port C::B to wx30...

Well, working on porting was my intent.
(From what I can tell Code::Blocks expects wxWidgets to be multi-lib under Linux.)

That's the default in all distros I know.
If you need wxWidgets build-flags for linux, I can post the configuration I use to build wxWidgets for C::B on my Fedora system later this day.

[oBFusCATed]

(From what I can tell Code::Blocks expects wxWidgets to be multi-lib under Linux.)

On linux I don't think we depend much on multilib vs monolithic, because wx-config should handle the differences for us.

I use the defaults configure flags, they work rather well (I can build C::B with them at least).

[Alpha]

With --enable-monolithic I have to tweak the project file, otherwise it errors at not being able to find the aui and propgrid libraries.  With --disable-compat28 --with-gtk=3 Code::Blocks builds fine, but will definitely be needing some bug fixing before it is useable .

[ollydbg]

Question about build C::B under Windows (32bit) against wx3.0.0. Is Compiling wxWidgets 2.9.0 to develop Code::Blocks (MSW) - CodeBlocks still the guide?

I just download the pre-build binaries (wxMSW-3.0.0_gcc471TDM_Dev.7z and wxWidgets-3.0.0_headers.7z) from official wx site, but I found that if was build with multi-libs, not the usually way I build wx2.8.12 in monolithic lib.

[gd_on]

Code

Is Compiling wxWidgets 2.9.0 to develop Code::Blocks (MSW) - CodeBlocks still the guide?

I don't think so. I have built it exactly as I build wxWidget 2.8.12 because with the switch USE_STC=0, I obtained compiling errors in the wxWidget build process.
So, my command line is :

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

Like that, it's OK.

look also in : http://forums.codeblocks.org/index.php/topic,18412.msg125957.html#msg125957

gd_on

[cacb]

General question relating to wx3.0 and Code::Blocks: Is wxSmith "fully compliant" with wxWidgets 3.0, i.e. are there any known problems?

I use wxSmith quite a lot, and I am in the process of upgrading to wx3.0. Can I assume that wxSmith+wx3.0 will be working well?

[oBFusCATed]

Can I assume that wxSmith+wx3.0 will be working well?

Of course you can't. We're not advertising it as such. Test it on your dialogs and report problems if you encounter any.

[cacb]

Can I assume that wxSmith+wx3.0 will be working well?

Of course you can't. We're not advertising it as such. Test it on your dialogs and report problems if you encounter any.

That's not a helpful reply. Sorry if my question was not clear. Perhaps this is clearer: Are there significant known problems in this area?

I will of course report anything I find, but I was hoping to avoid finding+reporting already known problem in this area, if any.

[ollydbg]

Hi, I would like to change the page title of wiki Compiling wxWidgets 2.9.0 to develop Code::Blocks (MSW) - CodeBlocks
To some kind of "Compiling_wxWidgets_3.0.0_to_develop_Code::Blocks_(MSW)", not sure how to do it in wiki, but I'm staring now.

[Alpha]

Renaming a page on the wiki is done by 'moving' it to the desired new title (I believe).

[ollydbg]

Renaming a page on the wiki is done by 'moving' it to the desired new title (I believe).

Yes, I did that already, you can see the updated wiki page now.

[stahta01]

By request I am testing the directions on this link http://wiki.codeblocks.org/index.php?title=Compiling_wxWidgets_3.0.0_to_develop_Code::Blocks_%28MSW%29

I normally build wxWidgets 3.0 branch; I am now confirming CB wx30 Project works with the unmodified wxWidgets 3.0.0.

NOTE: I only have these plugins normally enabled:
Compiler
Environment variables            Will be enabled during this testing normally I have it disabled.
Foreign projects importer       Will be enabled during this testing normally I have it disabled.
Project options manipulator   Will be enabled during this testing normally I have it disabled.
Scripted wizard
Source code formatter (AStyle)
ToolsPlus

NOTE: I do NOT have an easy to test 64 bit build machine; so, I am just doing the 32 bit build.

Edit: Testing with gcc version 4.8.1 (tdm-1) SJLJ

Tim S.

[killerbot]

the wiki says :

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"

I have tried last weekend like this :

Code

mingw32-make -f makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 VENDOR=cb

So I did not use : USE_XRC=1 , USE_OPENGL=1, CXXFLAGS="-fno-keep-inline-dllexport"


I am able to build all, but I suffer crashes. (32 bit and 64 bit). CB crashes at startup

[stahta01]

the wiki says :

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"

I have tried last weekend like this :

Code

mingw32-make -f makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 VENDOR=cb

So I did not use : USE_XRC=1 , USE_OPENGL=1, CXXFLAGS="-fno-keep-inline-dllexport"


I am able to build all, but I suffer crashes. (32 bit and 64 bit). CB crashes at startup

The USE_OPENGL=1 should NOT make a difference.
And, USE_XRC defaults to one; so, it should NOT make a difference.
This CXXFLAGS="-fno-keep-inline-dllexport" prevents linking errors and I think it should not make a runtime difference.
But, it might cause/fix a DLL load issue at runtime.

I am still building CB at this time; very slow PC.

CB Loaded without issues for me.

The wiki PATH setting step was NOT used instead I did this (not sure if valid on 64 bit systems.)

Code

SET PATH=C:\GreenApps\MinGW_GCC4_8x_SJLJ_TDM\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem

General Steps used to build CB after I built wxWidgets 3.0.0. Remember to set WX30 Global Variable.

Code

Started with these folders deleted
src/.objs30
src/devel30
src/output30

Build CB wx30 Project and Contrib wx30 Workspace.

Copy wxmsw30u_gcc_cb.dll to src/devel30

Run update30.bat

With all the Plugins enable CB Crashes on Startup.

Tim S.

[stahta01]

List of Plugins that tend to Crash CB svn 9537 built with wxWidgets 3.0.0 on CB Startup.
SpellChecker

NOTE: It is the only one to Crash CB on startup for me.

Note: "Open files list" Plugin gives error message when enabled but, it did NOT cause crash.

Tim S.

[gd_on]

Same for me as reported in : http://forums.codeblocks.org/index.php/topic,18741.msg128395.html#msg128395

After starting C::B (64 bits + wx 3.0) without spellchecker, I have also seen that FortranProject plugin may crash C::B. For example, if I use it to change the case of the string write (to obtain WRITE), with the Fortran/Change case menu, C::B crashes.

gd_on

[killerbot]

my 32 bit CB wx30 build  (with tdm gcc 481) crashes at startup. Disabling the "SpellChecker" plugin fixes that.

So when we want to switch to wx330, we need to fix he SpellChecker plugin ...

[oBFusCATed]

And the WatchesDlg...

[killerbot]

what's wrong with that dialog ?

[oBFusCATed]

Crashes. The keyboard shortcuts doesn't work, probably more problems will show up when these are fixed, but I can find the motivation to dig in to the changes that have happened in wxpropgrid integrated in wx3. wxSmith is probably affected, too.

[stahta01]

Crashes. The keyboard shortcuts doesn't work, probably more problems will show up when these are fixed, but I can find the motivation to dig in to the changes that have happened in wxpropgrid integrated in wx3. wxSmith is probably affected, too.

Patch that should be applied; I do NOT think it will fix the problem; but, who knows it might.

Since we are using wx3.0 propgrid; we should NOT have the one in SDK in the search list.

Tim S.

Code

Index: src/CodeBlocks_wx30.cbp
===================================================================
--- src/CodeBlocks_wx30.cbp	(revision 9532)
+++ src/CodeBlocks_wx30.cbp	(working copy)
@@ -166,7 +166,6 @@
 					<Add library="gdi32" />
 					<Add directory="devel30" />
 					<Add directory="sdk/scripting/lib" />
-					<Add directory="sdk/propgrid" />
 				</Linker>
 				<ExtraCommands>
 					<Add before="build_tools/autorevision/autorevision30 +wx +int +t . include/autorevision.h" />
Index: src/CodeBlocks_wx30_64.cbp
===================================================================
--- src/CodeBlocks_wx30_64.cbp	(revision 9532)
+++ src/CodeBlocks_wx30_64.cbp	(working copy)
@@ -166,7 +166,6 @@
 					<Add library="gdi32" />
 					<Add directory="devel30_64" />
 					<Add directory="sdk/scripting/lib" />
-					<Add directory="sdk/propgrid" />
 				</Linker>
 				<ExtraCommands>
 					<Add before="build_tools/autorevision/autorevision30_64 +wx +int +t . include/autorevision.h" />

[oBFusCATed]

Another serious problem with wx30 is that wxExecute is even more broken... I can't debug cb from inside cb

Code

#0 0x7ffff1f3b613	select() (/lib64/libc.so.6:??)
#1 0x7ffff37853c0	wxSelectSets::Select(this=0x7fffffff8750, nfds=18, tv=0x0) (./src/common/selectdispatcher.cpp:109)
#2 0x7ffff3786021	wxSelectDispatcher::DoSelect(this=0x7fffffff8a10, sets=..., timeout=-1) (./src/common/selectdispatcher.cpp:230)
#3 0x7ffff378610c	wxSelectDispatcher::Dispatch(this=0x7fffffff8a10, timeout=-1) (./src/common/selectdispatcher.cpp:249)
#4 0x7ffff379d0ad	(anonymous namespace)::BlockUntilChildExit(execData=...) (./src/unix/utilsunx.cpp:554)
#5 0x7ffff379e297	wxExecute(argv=0x15312b0, flags=17, process=0x121cd50, env=0x0) (./src/unix/utilsunx.cpp:853)
#6 0x7ffff379ce30	wxExecute(command=..., flags=17, process=0x121cd50, env=0x0) (./src/unix/utilsunx.cpp:475)
#7 0x7ffff37b8488	wxDoExecuteWithCapture(command=..., output=..., error=0x0, flags=17, env=0x0) (./src/common/utilscmn.cpp:679)
#8 0x7ffff37b8562	wxExecute(command=..., output=..., flags=17, env=0x0) (./src/common/utilscmn.cpp:706)
#9 0x7ffff2f99e8f	Compiler::EvalXMLCondition(this=0x157b470, node=0x1581620) (/home/obfuscated/projects/codeblocks/git/src/sdk/compiler.cpp:1209)
#10 0x7ffff2f951e7	Compiler::LoadDefaultOptions(this=0x157b470, name=..., recursion=1) (/home/obfuscated/projects/codeblocks/git/src/sdk/compiler.cpp:828)
#11 0x7ffff2f970f6	Compiler::LoadDefaultOptions(this=0x157b470, name=..., recursion=0) (/home/obfuscated/projects/codeblocks/git/src/sdk/compiler.cpp:1036)
#12 0x7ffff2f8c65c	Compiler::Reset(this=0x157b470) (/home/obfuscated/projects/codeblocks/git/src/sdk/compiler.cpp:161)
#13 0x7fffe01d5fb6	CompilerMINGW::CompilerMINGW(this=0x157b470, name=..., ID=...) (/home/obfuscated/projects/codeblocks/git/src/plugins/compilergcc/compilerMINGW.cpp:35)
#14 0x7fffe01b1665	CompilerGCC::DoRegisterCompilers(this=0x1232560) (/home/obfuscated/projects/codeblocks/git/src/plugins/compilergcc/compilergcc.cpp:851)
#15 0x7fffe01ad260	CompilerGCC::OnAttach(this=0x1232560) (/home/obfuscated/projects/codeblocks/git/src/plugins/compilergcc/compilergcc.cpp:360)
#16 0x7ffff2f5ab1a	cbPlugin::Attach(this=0x1232560) (/home/obfuscated/projects/codeblocks/git/src/sdk/cbplugin.cpp:71)
#17 0x7ffff3048097	PluginManager::AttachPlugin(this=0x11cfab0, plugin=0x1232560, ignoreSafeMode=false) (/home/obfuscated/projects/codeblocks/git/src/sdk/pluginmanager.cpp:195)
#18 0x7ffff304f045	PluginManager::LoadAllPlugins(this=0x11cfab0) (/home/obfuscated/projects/codeblocks/git/src/sdk/pluginmanager.cpp:1117)
#19 0x4d3cca	MainFrame::ScanForPlugins(this=0xa57f60) (/home/obfuscated/projects/codeblocks/git/src/src/main.cpp:1157)
#20 0x4ce6ad	MainFrame::MainFrame(this=0xa57f60, parent=0x0) (/home/obfuscated/projects/codeblocks/git/src/src/main.cpp:608)
#21 0x46109a	CodeBlocksApp::InitFrame(this=0x8d08a0) (/home/obfuscated/projects/codeblocks/git/src/src/app.cpp:437)
#22 0x4628d3	CodeBlocksApp::OnInit(this=0x8d08a0) (/home/obfuscated/projects/codeblocks/git/src/src/app.cpp:661)
#23 0x46868f	wxAppConsoleBase::CallOnInit(this=0x8d08a0) (/home/obfuscated/software/wx/include/wx-3.1/wx/app.h:93)
#24 0x7ffff370c0bd	wxEntry(argc=@0x7ffff3a7c130: 8, argv=0x8d04f0) (./src/common/init.cpp:479)
#25 0x7ffff370c1b4	wxEntry(argc=@0x7fffffffde8c: 8, argv=0x7fffffffdf78) (./src/common/init.cpp:507)
#26 0x460aa7	main(argc=8, argv=0x7fffffffdf78) (/home/obfuscated/projects/codeblocks/git/src/src/app.cpp:276)

Every time it stops here, while trying to execute GCC!

[Uskok]

Another serious problem with wx30 is that wxExecute is even more broken... I can't debug cb from inside cb

Every time it stops here, while trying to execute GCC!

Try to disable CC, it corrupted something very badly.

[oBFusCATed]

Try to disable CC, it corrupted something very badly.

This problem happens during startup, I doubt it is related to CC...

Edit: It is not, I've tried with disabled CC.

[oBFusCATed]

I'm able to reproduce the problem using the minimal sample in wx30's relatively latest git.

Here is the patch:

Code

diff --git a/samples/minimal/minimal.cpp b/samples/minimal/minimal.cpp
index a78e462..dc0709a 100644
--- a/samples/minimal/minimal.cpp
+++ b/samples/minimal/minimal.cpp
@@ -123,6 +123,7 @@ bool MyApp::OnInit()
     // few common command-line options but it could be do more in the future
     if ( !wxApp::OnInit() )
         return false;
+//    wxExecute(wxT("gcc -dumpversion"), wxEXEC_SYNC);//|wxEXEC_NOEVENTS);

     // create the main application window
     MyFrame *frame = new MyFrame("Minimal wxWidgets App");
@@ -197,4 +198,5 @@ void MyFrame::OnAbout(wxCommandEvent& WXUNUSED(event))
                  "About wxWidgets minimal sample",
                  wxOK | wxICON_INFORMATION,
                  this);
+    wxExecute(wxT("gcc -dumpversion"), wxEXEC_SYNC);//|wxEXEC_NOEVENTS);
 }

In order to reproduce this.
1. Apply the patch
2. Create a project for the minimal sample
3. Try to debug the sample using C::B

Results:
1. The sample hang at both wxExecute calls
2. The gcc executable is left as zombie process, so something doesn't close correctly
3. wxExecute never exits

I've not yet contacted the wx devs, but I'll do it as soon as I gather more data. Hopefully it is not reproducable on newer linuxes only.


@Jens and any dev or Linux user willing to try: Could you try to reproduce this problem?

[BlueHazzard]

here on Linux Mint 15 your example works with latest wxWidgets svn. No blocked or zombie process in debugging or running...
gcc 4.7.3
gdb (GDB) 7.5.91.20130417

greetings

[MortenMacFly]

Since we are using wx3.0 propgrid; we should NOT have the one in SDK in the search list.

That is true... and applied in trunk. Thank you!

[Uskok]

Try to disable CC, it corrupted something very badly.

This problem happens during startup, I doubt it is related to CC...

Edit: It is not, I've tried with disabled CC.

I wrote suggestion because under Linux (RH 6.4, wx30, sources from trunk) I had strange behavior of CodeBlocks. I was able to open project and after start compile only the messages from first file was omitted and the CB stops to response.  With disabled CC compilation process was OK.

[oBFusCATed]

Uskok: You are experiencing the same problem. But because the bug is a race condition or something like that is not 100% reproducible.

BlueHazzard: Can you post the versions of kernel, gtk+, glibc, glib?

[BlueHazzard]

libgtk 3.6.4-0ubuntu8
glibc 2.17
glib 2.36
kernel 3.8.0 (wow quite old oO)

greetings

[oBFusCATed]

BlueHazzard:
Could you try to rebuild wx30 with the --enable-debug configure option and try again to debug the minimal sample.
I've just rebuild my wx30 without using this option and C::B starts inside C::B without problems.
I can debug the minimal sample project, too.

[BlueHazzard]

with --enable-debug it is a different behaviour:
1) if i run it with gdb (with a break point on wxExecute) it works, and the process exits without error
1.1) if i run it with gdb step by step it blocks at utilsunix.cpp:853 in
 

Code

return BlockUntilChildExit(execData);

and i get a zombie gcc process
1.2) if i run it with gdb step by step without wxEXEC_NOEVENTS it blocks at utilsunix.cpp:862 and i get a zombie gcc process

in both cases i had to step until this line. If i only run with the debugger there was no error...

3.1) if i run it without debugger with wxEXEC_NOEVENTS i get a zombie gcc process
3.2) if i run it without debugger without wxEXEC_NOEVENTS the process ends without error

greetings

[oBFusCATed]

Thank you for your experiments. One question what do you mean by gdb: standalone gdb in terminal or gdb run by C::B's debugger plugin?

[BlueHazzard]

gdb in C::B plugin...
but there were no errors on the c::b site. The log was ok and also the application responded...
greetings