Author Topic: Code::blocks against wxWidgets 2.9.4  (Read 21205 times)

Offline gd_on

  • Lives here!
  • ****
  • Posts: 796
Re: Code::blocks against wxWidgets 2.9.4
« Reply #15 on: June 01, 2013, 12:17:40 pm »
OK. Tested finally with all 3 patches.
Looks better.
Always a problem with FortranProject plugin => C::B crash, OK if disabled.
Nevertheless, after a while (compiling, executing test programs), when I have closed C::B, I have obtained, one time, a similar wxwidget debug alert (no crash). I have not been able to reproduce the problem an other time  :(

gd_on
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Code::blocks against wxWidgets 2.9.4
« Reply #16 on: June 01, 2013, 01:08:11 pm »
I have committed patch# 3471 and 3473. Patch# 3472 is under testing.


I'm also getting following assert. CC gurus may want to take a look at this.
Quote
ASSERT INFO:
./src/unix/threadpsx.cpp(960): assert "GetState() == STATE_NEW" failed in Run(): thread may only be started once after Create()

BACKTRACE:
[1] wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)
[2] wxThread::Run()
[3] CodeCompletion::OnParserEnd(wxCommandEvent&)
[4] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[5] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
[6] wxEvtHandler::TryHereOnly(wxEvent&)
[7] wxEvtHandler::DoTryChain(wxEvent&)
[8] wxEvtHandler::ProcessEvent(wxEvent&)
[9] Parser::ProcessParserEvent(ParserCommon::ParserState, int, wxString const&)
[10] Parser::OnAllThreadsDone(CodeBlocksEvent&)
[11] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[12] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
[13] wxEvtHandler::TryHereOnly(wxEvent&)
[14] wxEvtHandler::ProcessEventLocally(wxEvent&)
[15] wxEvtHandler::ProcessEvent(wxEvent&)
[16] wxEvtHandler::ProcessPendingEvents()
[17] wxAppConsoleBase::ProcessPendingEvents()
[18] wxApp::DoIdle()
[19] g_main_context_dispatch
[20] g_main_loop_run
[21] gtk_main
[22] wxGUIEventLoop::Run()
Be a part of the solution, not a part of the problem.

Offline golgepapaz

  • Multiple posting newcomer
  • *
  • Posts: 44
Re: Code::blocks against wxWidgets 2.9.4
« Reply #17 on: June 01, 2013, 01:39:58 pm »
I have committed patch# 3471 and 3473. Patch# 3472 is under testing.

Cheers. For 3472, the wxListBook in EnvironmentSettingsDlg is created with wxLC_REPORT style bit
set for its list view. wxWidgets runtime complains about setting another style (wxLC_SMALL_ICON or
wxLC_ICON in this case) without clearing that bit.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Code::blocks against wxWidgets 2.9.4
« Reply #18 on: June 01, 2013, 07:35:19 pm »
I'm also getting following assert. CC gurus may want to take a look at this.
Yes, I stumbled across that, too. but the thing is: Its actually weird, because we do check if the thread is already running, as shown in the the code snippet:
Code
        if (   m_CCEnableHeaders
            && !m_SystemHeadersThreads.empty()
            && !m_SystemHeadersThreads.front()->IsRunning()
            && m_NativeParser.Done() )
        {
            m_SystemHeadersThreads.front()->Run();
        }
So either its a weird timing issue (maybe m_NativeParser.Done() takes long and therefore the thread already got started meanwhile) or I simply don't get it... there is no other thread we launch there.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline gd_on

  • Lives here!
  • ****
  • Posts: 796
Re: Code::blocks against wxWidgets 2.9.4
« Reply #19 on: June 06, 2013, 02:57:24 pm »
Quote
1) Ignore the warning message about libwxPdfDocument.a, it is linked correctly, but the target dependencies in the exporter plugin are incorrect.
If I remember correctly, I corrected this on linux, but obviously not on windows (do not use it often).
Here are two small patches to solve this warning when building C::B workspace under Windows.

for wx 2.8 :
Code
Index: Exporter.cbp
===================================================================
--- Exporter.cbp (révision 9138)
+++ Exporter.cbp (copie de travail)
@@ -58,7 +58,7 @@
  <Target title="default">
  <Option output="..\..\..\devel\share\CodeBlocks\plugins\Exporter" prefix_auto="0" extension_auto="1" />
  <Option object_output="..\..\..\.objs\plugins\contrib\source_exporter" />
- <Option external_deps="libwxPdfDocument.a;" />
+ <Option external_deps="wxPdfDocument\lib\libwxPdfDocument.a;" />
  <Option type="3" />
  <Option compiler="gcc" />
  <Option parameters="--debug-log --multiple-instance -na -ns -nd" />

and the same one for wx 2.9 :
Code
Index: Exporter_wx29.cbp
===================================================================
--- Exporter_wx29.cbp (révision 9138)
+++ Exporter_wx29.cbp (copie de travail)
@@ -58,7 +58,7 @@
  <Target title="default">
  <Option output="..\..\..\devel29\share\CodeBlocks\plugins\Exporter" prefix_auto="0" extension_auto="1" />
  <Option object_output="..\..\..\.objs29\plugins\contrib\source_exporter" />
- <Option external_deps="libwxPdfDocument.a;" />
+ <Option external_deps="wxPdfDocument\lib29\libwxPdfDocument.a;" />
  <Option type="3" />
  <Option compiler="gcc" />
  <Option parameters="--debug-log --multiple-instance -na -ns -nd" />

gd_on
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).