wxWidgets 3.0.3 released

[stahta01]

Since wxWidgets 3.0.3 released; I am going to once more try to fix the CB Projects and Wizards to use the wxTeam prebuilt binaries. Maybe this time, I will finish it and have a CB Dev like the way I do at least part of the work.

https://github.com/wxWidgets/wxWidgets/releases/tag/v3.0.3

Tim S.

[killerbot]

Yesterday I have tried to build CB with it : mixed results.

Environment :
- Win 10 (64 bit)
- TDM-gcc 5.1.0 ==> which creates by default 64 bit targets (I used it like that)

I build wx like I used to build the 2.8.12, that is like described on the nightly cookbook. ==> no problems

I did NOT specify -std=c++11 !!!!

(need to investigate if this is not the default gcc 5.1, otherwise my build of wx is not correct)

Then I build CB by using the wx30_64 workspace.

The project files of the wx30_64 explicitly specify -std=c++11

The build failed because the fortran plug-in does not compile, it needs in parserf.cpp to include <wx/regex.h>.

The I can launch the freshly build CB, it comes up nicely, but without any interaction a few seconds later it crashes.

[stahta01]

Edit4: Deleted wxWidgets message that went away after I deleted the MSys2 GCC 6.3.0 DLLs.

The MinGW32 GCC TDM 5.1.0 gets the above message using the wxTeam built binary with edited project.
Now, it looks like I need to build wxWidgets using my "MinGW32 GCC TDM 5.1.0" to see if the error was caused by a compiler version/build type issue.

Edit: It never really displays the CB IDE before it crashes.
Edit3: It stopped crashing after I deleted the DLLs left over from the MSys2 GCC 6.3.0 testing.
Edit2: Testing on Windows 10 32 bit.

NOTE: The wxTeam used the flags below to build their GCC 510TDM binary

Code Select Expand


CXXFLAGS=-fno-keep-inline-dllexport -std=gnu++11


Tim S.

[killerbot]

as for gcc, I think the default mode in 5.x is not "c++11", in 6.x it became "The default mode for C++ is now -std=gnu++14 instead of -std=gnu++98".

So I think indeed when we build wx with the 5.x we should clearly specify the standard we want to use.
I think it is best to stick to official standard and not gnu extension ==> -std=c++11

So when mixing what you saw from wxTeam (no idea what wxTeam is ) and our cookbook we should get something like:

Code Select Expand


CXXFLAGS+=-fpermissive -fno-keep-inline-dllexport -std=c++11


Need to see what the correct syntax is to end up with the following invocation for building wx :

Code Select Expand


mingw32-make -f makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 vendor=CB CXXFLAGS+=-fpermissive -fno-keep-inline-dllexport -std=gnu++11


should it it be CXXFLAGS+="blablablablabla ablablalb "  ?

[stahta01]

This is the syntax I think it should use.

Code Select Expand


CXXFLAGS="-fpermissive -fno-keep-inline-dllexport -std=gnu++11"


Full command below:

Code Select Expand


mingw32-make -f makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 vendor=CB CXXFLAGS="-fpermissive -fno-keep-inline-dllexport -std=gnu++11"


Edit: I am using wxTeam in place of the wxWidgets development team; in this exact case I mean the sub-set of people who created the wxWidgets multilib binaries I am using.

[killerbot]

note that out cookbook says += instead of =  for CXXFLAGS, we want to append our settings, and not just overwrite.

[oBFusCATed]

The append is useful probably if you already have an env variable named CXXFLAGS.

[killerbot]

correct, but I have no clue if wx might already have if defined itself somewhere in its makefiles ....

[oBFusCATed]

This won't make a difference in this case. The old value should be taken from the environment and not from the makefile.

[killerbot]

I have done a new build.

Windows 10 64-bit
TDM-GCC 5.1.0 (by default builds 64-bit applications)

Wx 3.0.3

Wx build as :

Code Select Expand


mingw32-make -f makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 VENDOR=cb CXXFLAGS+="-fpermissive -fno-keep-inline-dllexport -std=c++11"


And then build CB (and plug-ins) based on : CodeBlocks_wx30_64.workspace

It all builds.

Launch CB ==> entire GUI comes up, and after a few seconds CB crashed (so not doing anything at all in CB).

When launching the outcome in "devel30_64" (so not stripping), this is rpt info (some snippets from it) :

Code Select Expand


Error occurred on Saturday, May 6, 2017 at 15:24:08.

codeblocks.exe caused an Access Violation at location 0000000064520BD0 in module wxmsw30u_gcc_cb.dll Reading from location 0000000000000019.

AddrPC           Params
0000000064520BD0 0000000000000000 0000000000000000 0000000000000070  wxmsw30u_gcc_cb.dll!wxDropTarget::Revoke
0000000064555A80 00007FFA05FFBE53 8000001000000000 0000000000000000  wxmsw30u_gcc_cb.dll!wxWindow::HandleDestroy
0000000064561975 0000000000000002 0000000000000000 000000001D82BC50  wxmsw30u_gcc_cb.dll!wxWindow::MSWHandleMessage
0000000064551B8C 00003F491629097D 0000000000000001 0000000000000000  wxmsw30u_gcc_cb.dll!wxWindow::MSWWindowProc
0000000064608931 0000000080000010 0000000000000001 0000000000000000  wxmsw30u_gcc_cb.dll!wxTextCtrl::MSWWindowProc
00007FFA05FFBC50 0000000000000388 0000000064559F90 00000000001206E6  USER32.dll!UserCallWinProcCheckWow
00007FFA05FFB94C 0000000000000000 0000000000000000 0000000000000000  USER32.dll!DispatchClientMessage
00007FFA060111F3 0000000000000080 00007FFA06071000 00007FFA02E223C4  USER32.dll!__fnDWORD
00007FFA067F90B4 000000006455A564 0000000003BE19A0 00000000652B9C80  ntdll.dll!KiUserCallbackDispatch
00007FFA02E223C4 0000000003BE19A0 00000000652B9C80 00000000652B9C80  win32u.dll!NtUserDestroyWindow
000000006455A564 0000000002228DE0 00000000652880E0 00000000652880E0  wxmsw30u_gcc_cb.dll!wxWindow::~wxWindow
00000000004ACAC8 0000000003BE19A0 000000000F9EA100 000000006528DD50  codeblocks.exe! ??   [D:/Codeblocks/src/src/splashscreen.cpp @ 181]
   179: }
   180:
>  181: cbSplashScreen::~cbSplashScreen()
   182: {
   183:     m_timer.Stop();
00000000004ACAF7 0000000003BE19A0 00000000019BF990 0000000065288120  codeblocks.exe! ??   [D:/Codeblocks/src/src/splashscreen.cpp @ 184]
   182: {
   183:     m_timer.Stop();
>  184: }
   185:
0000000064303477 0000000000000000 0000000000000000 0000000000000008  wxmsw30u_gcc_cb.dll!wxAppConsoleBase::DeletePendingObjects
00000000643034E5 0000000000000012 0000000000000008 000000000FD44740  wxmsw30u_gcc_cb.dll!wxAppConsoleBase::ProcessIdle
000000006462A011 0000000065288120 00007FFA06459A00 0000000000000000  wxmsw30u_gcc_cb.dll!wxAppBase::ProcessIdle
000000006433D7F9 0000000002228DE0 000000000FD44740 00000000019BFBA0  wxmsw30u_gcc_cb.dll!wxEventLoopManual::DoRun
000000006433D3FD 0000000000000006 0000000200000006 000000001D947960  wxmsw30u_gcc_cb.dll!wxEventLoopBase::Run
0000000064307F0A 000000000000000E 00000000021E19B0 0000000000000000  wxmsw30u_gcc_cb.dll!wxAppConsoleBase::MainLoop
0000000000404F56 0000000002228DE0 0000000000400000 0000000000000001  codeblocks.exe!OnRun  [D:/Codeblocks/src/src/app.cpp @ 850]
   848:     try
   849:     {
>  850:         int retval = wxApp::OnRun();
   851:         // wx 2.6.3 docs says that OnRun() function's return value is used as exit code
   852:         return m_Batch ? m_BatchExitCode : retval;
0000000064387ADA 00000000019BFDE0 0000000000400000 000000000221EB90  wxmsw30u_gcc_cb.dll!wxEntryReal
00000000644794D4 0000000000000000 000000000000002C 000000000000002C  wxmsw30u_gcc_cb.dll!wxEntry
0000000000402205 0000000000400000 0000000000000000 00000000000E395E  codeblocks.exe!WinMain  [D:/Codeblocks/src/src/app.cpp @ 322]
   320: } // namespace
   321:
>  322: IMPLEMENT_APP(CodeBlocksApp) // TODO: This gives a "redundant declaration" warning, though I think it's false. Dig through macro and check.
   323:
   324: BEGIN_EVENT_TABLE(CodeBlocksApp, wxApp)
00000000004013E8 0000000000000000 0000000000000000 0000000000000000  codeblocks.exe!__tmainCRTStartup  [C:/crossdev/src/mingw-w64-v4-git/mingw-w64-crt/crt/crtexe.c @ 332]
00000000004014EB 0000000000000000 0000000000000000 0000000000000000  codeblocks.exe!WinMainCRTStartup  [C:/crossdev/src/mingw-w64-v4-git/mingw-w64-crt/crt/crtexe.c @ 184]
00007FFA03EC2774 0000000000000000 0000000000000000 0000000000000000  KERNEL32.DLL!BaseThreadInitThunk
00007FFA067C0D61 0000000000000000 0000000000000000 0000000000000000  ntdll.dll!RtlUserThreadStart


Could this indicate that something is going wrong in the destruction (closing) of the splash screen ?

Anyone else having a working build with Win10 (64 bit) and wx 3.0.3 ?

[stahta01]

Anyone else having a working build with Win10 (64 bit) and wx 3.0.3 ?

Will Windows 7 (64 bit) and wx 3.0.3, help?

If yes, I could build on a old laptop (if it works long enough).

Tim S.

[killerbot]

Well the idea is to have CB officially switch to wx 3.0.3 and ditch wx 2.8.12.

But then we need to get a working CB (nightly), in the end I will probably then make the nightlies on my Win10 partition (64 bit), instead of on my old WinXp32bit virtual box. I might make sense to no longer provide 32 bit.
But my build crashes, so it would be interesting to know if anyone out there on windows can get to a success with wx 3.0.3, and then 64bit, ....

So I think a win7 is already at starting point, I assuming the problem is more CB and wx 3.0.3, and 64 bit (and not so much win7 versus win10) ....

[killerbot]

when I commented out the lines interacting with the "Splash" class in the OnInit method in app.cpp, then CB starts OK.

Then I activated them again, and that build is indeed crashing again.

[oBFusCATed]

Isn't the idea to switch directly to 3.1 on windows? 3.0.3 doesn't have hidpi support as far as I know.

Have you tried to use full debug build (both cb and wx build in debug mode) inside a debugger?

[killerbot]

I think I saw the same problem months ago with 3.1.

Note that 3.1 is not an official release, it is a development release, which has been the objection in the past not to go straight to this one ?