The link to the wxWidgets DLL is incorrect, there is a stray "-2" at the end of the filename.
Hi,
is it necessary to keep all these libs in installation?:
libwxSpellChecker.a
libhunspell.a
libwxPdfDocument.a
libz.a
libbz2_help.a
libbz2_devpak.a
libwxsmithlib.a
libwxmathplot.a
libwxled.a
libwxkwic.a
libwxspeedbutton.a
libwximagepanel.a
libwxcustombutton.a
libwxchartctrl.a
libwxflatnotebook.a
libdepslib.a
libcodeblocks.a
libwxscintilla_cb.a
libsquirrel.a
libtxml.a
libsqplus.a
libsqstdlib.a
Hi,
is it necessary to keep all these libs in installation?:
libwxSpellChecker.a
libhunspell.a
libwxPdfDocument.a
libz.a
libbz2_help.a
libbz2_devpak.a
libwxsmithlib.a
libwxmathplot.a
libwxled.a
libwxkwic.a
libwxspeedbutton.a
libwximagepanel.a
libwxcustombutton.a
libwxchartctrl.a
libwxflatnotebook.a
libdepslib.a
libcodeblocks.a
libwxscintilla_cb.a
libsquirrel.a
libtxml.a
libsqplus.a
libsqstdlib.a
Normally the answer is they are not needed; they would be good to keep if you are writing an CB Plugin.Thanks, I got it. They are for C::B plugin developers.
Tim S.
I got first RPT (see attachment) on close C::B after usage with new project.
00000000709B93BD 0000000002E7B320 0000000000000000 000000000022E750 codeblocks.dll!DebuggerManager::DestoryWindows
00000000709B7325 0000000002E7B320 0000000005AED920 000000000022E7B0 codeblocks.dll!DebuggerManager::UnregisterDebugger
0000000070964028 0000000005AED920 0000000070D1A501 000000000022E830 codeblocks.dll!cbDebuggerPlugin::OnRelease
0000000070963B2B 0000000005AED920 0000000005AED901 00000000057F7D30 codeblocks.dll!cbPlugin::Release
DestoryWindows()
I got first RPT (see attachment) on close C::B after usage with new project.Steps to reproduce?
-------------- Build: Release in KanjiNoKenkyuu (compiler: GNU GCC Compiler)---------------
[ 3.7%] mingw32-g++.exe -Wall -std=gnu++11 -m64 -pipe -mthreads -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -O3 -IC:\Lib\wxWidgets\3_1_4\include -I..\..\..\sources\KanjiNoKenkyuu -I..\..\..\sources\tinyxml -I..\..\..\sources\analysis -I..\..\..\sources\dataBase -I..\..\..\sources\view -I..\..\..\sources\view\kanji -I..\..\..\sources\view\tree -I..\..\..\sources\view\logging -I..\..\..\sources\view\dialogue -IC:\Lib\wxWidgets\3_1_4\lib\gcc_dll_MinGW_9_2_0_TDM_64_SEH\msw -c C:\Project\Nihongo_Shiryou\SandBox\trunk\sources\analysis\anls_Analysis.cpp -o obj\Release\sources\analysis\anls_Analysis.o
C:\Project\Nihongo_Shiryou\SandBox\trunk\sources\analysis\anls_Analysis.cpp:1:0: sorry, unimplemented: 64-bit mode not compiled in
/*!
^
Process terminated with status 1 (0 minute(s), 0 second(s))
1 error(s), 0 warning(s) (0 minute(s), 0 second(s))
Build log saved as:
file://C:/Project/Nihongo_Shiryou/SandBox/trunk/workspace/CodeBlocks/KanjiNoKenkyuu/KanjiNoKenkyuu_build_log.html
[ 3.7%] x86_64-w64-mingw32-g++.exe -Wall -std=gnu++11 -m64 -pipe -mthreads -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -O3 -IC:\Lib\wxWidgets\3_1_4\include -I..\..\..\sources\KanjiNoKenkyuu -I..\..\..\sources\tinyxml -I..\..\..\sources\analysis -I..\..\..\sources\dataBase -I..\..\..\sources\view -I..\..\..\sources\view\kanji -I..\..\..\sources\view\tree -I..\..\..\sources\view\logging -I..\..\..\sources\view\dialogue -IC:\Lib\wxWidgets\3_1_4\lib\gcc_dll_MinGW_9_2_0_TDM_64_SEH\msw -c C:\Project\Nihongo_Shiryou\SandBox\trunk\sources\analysis\anls_Analysis.cpp -o obj\Release\sources\analysis\anls_Analysis.o
It was like this:I got first RPT (see attachment) on close C::B after usage with new project.Steps to reproduce?
Does it happen every time?
Does it happen with older night builds?
Yesterday I have tried out your new nightly 12446 from May the 11th. The latest version I used was a self build SVN 12240 from December 20201. Can you try to find the night build which changed behaviour?
@nenin: We need something that is more reproducible in order to fix the problem. It seems something somewhere is corrupting memory, but where - hard to tell. Please lets us know if this persists or the frequency of the crashes increases.Of course.
If you compare both build-reports you will see that the binaries called for the compilation are differentWhy did you change that ? May be an installer (or Auto-detect) has done this for you, but you can revert this.
The new nightly calls : mingw32-g++.exe
The old nightly calls : x86_64-w64-mingw32-g++.exe
This is just a supposition ...Please accept my apologize if my words are to rough.
compiler: Add proper version comparison to compiler's XML parser (ticket #1041, thanks Miguel Gimenez)
Would it be possible to do a bisect with own builds and tell us which revision broke it?
There aren't that many revision so finding the broken one shouldn't take that much time.
<gcv>
<sets>
<default>
<wx_64>
<BASE>
<str>
<![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12]]>
</str>
</BASE>
<INCLUDE>
<str>
<![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12\include]]>
</str>
</INCLUDE>
<LIB>
<str>
<![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12\lib]]>
</str>
</LIB>
</wx_64>
<wx>
<BASE>
<str>
<![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12]]>
</str>
</BASE>
<INCLUDE>
<str>
<![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12\include]]>
</str>
</INCLUDE>
<LIB>
<str>
<![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12\lib]]>
</str>
</LIB>
</wx>
<wx_32bit>
<BASE>
<str>
<![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12]]>
</str>
</BASE>
<INCLUDE>
<str>
<![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12\include]]>
</str>
</INCLUDE>
<LIB>
<str>
<![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12\lib]]>
</str>
</LIB>
</wx_32bit>
<wx30>
<BASE>
<str>
<![CDATA[C:\Lib\wxWidgets\3_0_4\MinGW_5_1_0_32bit]]>
</str>
</BASE>
<INCLUDE>
<str>
<![CDATA[C:\Lib\wxWidgets\3_0_4\MinGW_5_1_0_32bit\include]]>
</str>
</INCLUDE>
<LIB>
<str>
<![CDATA[C:\Lib\wxWidgets\3_0_4\MinGW_5_1_0_32bit\lib]]>
</str>
</LIB>
</wx30>
<unittest>
<BASE>
<str>
<![CDATA[C:\Tool\Development\UnitTest]]>
</str>
</BASE>
<INCLUDE>
<str>
<![CDATA[C:\Tool\Development\UnitTest\UnitTest++\src]]>
</str>
</INCLUDE>
<LIB>
<str>
<![CDATA[C:\Tool\Development\UnitTest\lib]]>
</str>
</LIB>
</unittest>
<wx31_64>
<BASE>
<str>
<![CDATA[C:\Lib\wxWidgets\3_1_3]]>
</str>
</BASE>
<INCLUDE>
<str>
<![CDATA[C:\Lib\wxWidgets\3_1_3\include]]>
</str>
</INCLUDE>
<LIB>
<str>
<![CDATA[C:\Lib\wxWidgets\3_1_3\lib]]>
</str>
</LIB>
</wx31_64>
<cb>
<BASE>
<str>
<![CDATA[C:\Project\_SVN\CodeBlocks\trunk\src]]>
</str>
</BASE>
</cb>
<cb_release_type>
<BASE>
<str>
<![CDATA[-o2]]>
</str>
</BASE>
</cb_release_type>
<boost>
<BASE>
<str>
<![CDATA[C:\Lib\boost\boost_1_57_0]]>
</str>
</BASE>
<INCLUDE>
<str>
<![CDATA[C:\Lib\boost\boost_1_57_0]]>
</str>
</INCLUDE>
</boost>
<gcc_libs>
<BASE>
<str>
<![CDATA[C:\Tool\Development\MinGW\MinGW_8_1_0\bin_64_SJLJ\mingw64]]>
</str>
</BASE>
<INCLUDE>
<str>
<![CDATA[$(#gcc.BASE)\include\]]>
</str>
</INCLUDE>
<LIB>
<str>
<![CDATA[$(#gcc.BASE)\lib\]]>
</str>
</LIB>
<LIBSTDCPP_A>
<str>
<![CDATA[gcc\x86_64-w64-mingw32\9.2.0\libstdc++.a]]>
</str>
</LIBSTDCPP_A>
<LIBWINPTHREAD_A>
<str>
<![CDATA[..\x86_64-w64-mingw32\lib\libwinpthread.a]]>
</str>
</LIBWINPTHREAD_A>
<LIBGCC_S_A>
<str>
<![CDATA[..\x86_64-w64-mingw32\lib\libgcc_s.a]]>
</str>
</LIBGCC_S_A>
</gcc_libs>
<gcc>
<BASE>
<str>
<![CDATA[C:\Tool\Development\MinGW\MinGW_9_2_0_TDM\bin_64_SEH]]>
</str>
</BASE>
<INCLUDE>
<str>
<![CDATA[$(#gcc.BASE)\include\]]>
</str>
</INCLUDE>
<LIB>
<str>
<![CDATA[$(#gcc.BASE)\lib\]]>
</str>
</LIB>
<COMPILER_C>
<str>
<![CDATA[x86_64-w64-mingw32-gcc.exe]]>
</str>
</COMPILER_C>
<COMPILER_CPP>
<str>
<![CDATA[x86_64-w64-mingw32-g++.exe]]>
</str>
</COMPILER_CPP>
<COMPILER_RES>
<str>
<![CDATA[windres.exe]]>
</str>
</COMPILER_RES>
<LINKER_DYN>
<str>
<![CDATA[x86_64-w64-mingw32-g++.exe]]>
</str>
</LINKER_DYN>
<LINKER_STAT>
<str>
<![CDATA[x86_64-w64-mingw32-gcc-ar.exe]]>
</str>
</LINKER_STAT>
<MAKE>
<str>
<![CDATA[mingw32-make.exe]]>
</str>
</MAKE>
<LIBSTDCPP_A>
<str>
<![CDATA[gcc\x86_64-w64-mingw32\9.2.0\libstdc++.a]]>
</str>
</LIBSTDCPP_A>
</gcc>
</default>
</sets>
<ACTIVE>
<str>
<![CDATA[default]]>
</str>
</ACTIVE>
</gcv>
<gcc>
<NAME>
<str>
<![CDATA[GNU GCC Compiler]]>
</str>
</NAME>
<MASTER_PATH>
<str>
<![CDATA[$(#gcc.BASE)]]>
</str>
</MASTER_PATH>
<EXTRA_PATHS>
<str>
<![CDATA[C:\Tool\Development\MinGW\AddOn\bison\bison_2_1\bin;C:\Tool\Development\MinGW\AddOn\flex\flex_2_5_4a_1\bin;C:\Tool\Kompress\Zip\3_0\bin;]]>
</str>
</EXTRA_PATHS>
<C_COMPILER>
<str>
<![CDATA[$(#gcc.COMPILER_C)]]>
</str>
</C_COMPILER>
<CPP_COMPILER>
<str>
<![CDATA[$(#gcc.COMPILER_CPP)]]>
</str>
</CPP_COMPILER>
<LINKER>
<str>
<![CDATA[$(#gcc.LINKER_DYN)]]>
</str>
</LINKER>
<LIB_LINKER>
<str>
<![CDATA[$(#gcc.LINKER_STAT)]]>
</str>
</LIB_LINKER>
<RES_COMPILER>
<str>
<![CDATA[$(#gcc.COMPILER_RES)]]>
</str>
</RES_COMPILER>
<MAKE>
<str>
<![CDATA[$(#gcc.MAKE)]]>
</str>
</MAKE>
</gcc>
<tools>
<tool00>
<NAME>
<str>
<![CDATA[open project folder]]>
</str>
</NAME>
<COMMAND>
<str>
<![CDATA[explorer.exe ]]>
</str>
</COMMAND>
<PARAMS>
<str>
<![CDATA[${PROJECT_DIR}]]>
</str>
</PARAMS>
<WORKINGDIR>
<str>
<![CDATA[]]>
</str>
</WORKINGDIR>
<LAUNCHOPTION int="2" />
</tool00>
</tools>
You are asking me to test more than 20 revisions right?More like lg2(20), if you use binary search.
Usually a build takes half a day on my computer parallel to my work I need at least 20 days or more.Hard to believe. Even my old core2quad could build the core stuff in 2-3 minutes.
Hard to believe. Even my old core2quad could build the core stuff in 2-3 minutes.
I think the real problem is located in the evaluation of the conf-file were all this configurations are stored. In my today's first post I have also added the conf-file (ok as txt file but this means for you that you have to change the file-attachment back as already discussed).Yes.. i think our config file parsing/saving is broken, prone to create erroneous files... I have this problem from time to time, that the compiler flags are not valid any more. I am not able to reproduce this and that is a big problem...
windows is !significantly! slower then linux when it comes to building codeblocks...
@Obfuscated regarding the problem of @eckard_klotzI'm not sure what config-kill-problem you're talking about, but as far as I understand it the problem is 100% reproducible - it happens every time. @eckard_klotz could correct me if this is not the case of course.
i think he hits the bug where we kill our config file...
I'm not sure what config-kill-problem you're talking about, but as far as I understand it the problem is 100% reproducible - it happens every time. @eckard_klotz could correct me if this is not the case of course.
I think i can reproduce your error. But i think what is actually happening (and i can not understand why it only happens now): The ask dialog of the personality is not working...
if i use the flag --personality="MinGW_9_2_0bit_TDM" everything works
can you confirm this?