Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on May 11, 2021, 06:55:33 pm

Title: The 11 May 2021 build (12446) is out.
Post by: killerbot on May 11, 2021, 06:55:33 pm
We switched to wx 3.1.5 --> download the new wx dll's see link below

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works (http://forums.codeblocks.org/index.php/topic,3232.0.html).

A link to the unicode windows wxWidget dll(s) for Code::Blocks : https://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw31u_gcc_cb_wx315_2D_gcc810-mingw64.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls8.1.0.7z


The 11 May 2021 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2021/CB_20210511_rev12446_win64.7z
  - Linux :
   none

The current SDK version is : 2.8.0

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 11 May 2021 build (12446) is out.
Post by: gd_on on May 12, 2021, 02:47:26 pm
as far as I know, files libsqplus.a and libsqstdlib.a are no more generated with the last worskspace generation. So those files were generated for/with a previous nightly.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: Miguel Gimenez on May 12, 2021, 03:00:24 pm
The link to the wxWidgets DLL is incorrect, there is a stray "-2" at the end of the filename.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: oBFusCATed on May 12, 2021, 09:46:01 pm
Ubuntu night builds can be found here: https://launchpad.net/~fuscated/+archive/ubuntu/codeblocks-nightly
Title: Re: The 11 May 2021 build (12446) is out.
Post by: killerbot on May 12, 2021, 11:21:42 pm
The link to the wxWidgets DLL is incorrect, there is a stray "-2" at the end of the filename.

fixed, thanks for the feedback.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: nenin on May 13, 2021, 08:18:35 am
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

Title: Re: The 11 May 2021 build (12446) is out.
Post by: ollydbg on May 13, 2021, 03:55:24 pm
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


I guess you want to build a program, and link it to those libraries?
Basically, you can use gcc's linker to directly link you exe to the dlls.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: stahta01 on May 13, 2021, 04:11:38 pm
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.

Tim S.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: Xaviou on May 13, 2021, 11:42:48 pm
Hi

OS X version of this rev can be downloaded from my Google Drive (https://drive.google.com/drive/folders/1-r9cbW1I8ZkaCt6iYDhcXH981n5FJTpV?usp=sharing).
There is a specific dmg file for each version of the os (10.13, 10.14, 10.15 and 11.1).

32 bits version for Windows can also be found in the same place.

Debian Stretch and Buster (32 and 64 bits) can be installed from my repo (https://wxstuff.xaviou.fr/article/debian-repository.html).

Regards
Xav'
Title: Re: The 11 May 2021 build (12446) is out.
Post by: nenin on May 14, 2021, 09:30:25 am
Normally the answer is they are not needed; they would be good to keep if you are writing an CB Plugin.
Tim S.
Thanks, I got it.  They are for C::B plugin developers.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: nenin on May 15, 2021, 08:29:52 am
I got first RPT (see attachment) on close C::B after usage with new project.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: ollydbg on May 15, 2021, 08:58:19 am
I got first RPT (see attachment) on close C::B after usage with new project.

It looks like the crash is from the debugger plugin, see:

Code
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
Title: Re: The 11 May 2021 build (12446) is out.
Post by: Miguel Gimenez on May 15, 2021, 10:03:38 am
The bug is here  :P

Code
DestoryWindows()
Title: Re: The 11 May 2021 build (12446) is out.
Post by: oBFusCATed on May 15, 2021, 11:37:31 am
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?
Title: Re: The 11 May 2021 build (12446) is out.
Post by: eckard_klotz on May 16, 2021, 10:52:16 am
Hello Developers.

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 2020 where I added the symbol-browser patch https://sourceforge.net/p/codeblocks/tickets/1031/ (https://sourceforge.net/p/codeblocks/tickets/1031/) and the XPM editor https://forums.codeblocks.org/index.php/board,14.0.htmlr (https://forums.codeblocks.org/index.php/board,14.0.htmlr).

First of all thanks that you were able to activate the symbol-browser again.


However with this nightly I'm not able to build any more my project created and buildable without problems with my older Code::Blocks version.

If the compilation starts I get the error-message sorry, unimplemented: 64-bit mode not compiled in
Quote
-------------- 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
 


I can understand if your first reaction would be to say that this is a compiler problem. But the same project is buildable with my self-build Code::Blocks from December 2020. And the only change in my tool-environment I have done is using the nightly from 2021 May the 11th with the binaries provided in this topic.

If I build the same project with my older Code::Blocks the first compilation command is this:
Quote
[  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


If you compare both build-reports you will see that the binaries called for the compilation are different



I call Code::Blocks with a personalities which define several global variables used in my project for an easy change between different build-environments. For this experiment I used certainly the same personality with both Code::Blocks versions.

For the compiler tool-chain I use  global variable gcc you could see in the image CB_12240_gcc_paths.png in the attached zip-file. The image CB_12240_compiler_toolchain_executables.png show how this global variables are used in the configuration of Code::Blocks. All this works without problems in my Code::Blocks version 12240 from December 2020.

Now I tried to view the same definitions in the new nightly and surprise surprise the global variables called gcc are not shown any more, as you could see in the image CB_12446_gcc_paths.png and the compiler tool-chain configuration was set back to the default, as you could see in the image CB_12446_compiler_toolchain_executables.png

For me it seems that Code::Blocks has a problem with global variable which names start with gcc .



I have added the used personality file and the Code::Blocks project file as text-files in the attached zip-file.


Thanks for your patience while reading my post.

Please stay well and healthy,
                                          Eckard Klotz.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: nenin on May 16, 2021, 10:53:16 am
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?
It was like this:
I  installed this build in clear folder.
I opened some old project to check is everything OK- it looks OK  (compiler recognition, default settings, etc.)
I started new console project, work with it for some time (few hours) including debug sessions, than I did "Save all" and on exit and it generated RPT.
I did not tried to reproduce it in 100%, simple tests like create project- debug- "save all"- close C::B - does not lead to crash on exit.
With last few years nighties I did not face such problem.
I`m on Win7 64b, gcc- winlibs 10.2 32b, gdb: GNU gdb (ssbssa-1) 10.1.90.20201024-git
Title: Re: The 11 May 2021 build (12446) is out.
Post by: oBFusCATed on May 16, 2021, 11:19:24 am
@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.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: oBFusCATed on May 16, 2021, 11:25:46 am
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 2020
1. Can you try to find the night build which changed behaviour?
2. What is the exact command line you use to start CB?
Title: Re: The 11 May 2021 build (12446) is out.
Post by: nenin on May 16, 2021, 11:57:13 am
@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.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: gd_on on May 16, 2021, 12:28:16 pm
@eckard_klotz
Quote
If you compare both build-reports you will see that the binaries called for the compilation are different

    The new nightly calls : mingw32-g++.exe
    The old nightly calls : x86_64-w64-mingw32-g++.exe
Why did you change that ? May be an installer (or Auto-detect) has done this for you, but you can revert this.
In a standard tdm-64 installation, mingw32-g++.exe does not exist, but x86_64-w64-mingw32-g++.exe (or simply g++.exe which is the same executable) exists. If you want to use the same compiler version as previously, the same configuration path should work. Take care of the order in your path variable !
So, may be you have an other mingw32 in your path, a 32 bits one, so this can give such problem.
This is just a supposition ...
Title: Re: The 11 May 2021 build (12446) is out.
Post by: eckard_klotz on May 16, 2021, 02:16:20 pm
Hello oBFusCATed and gd_on

Thanks for your fast response

@gd_on
You wonder why I have changed the called binary.


What you describe about the windows-path variable may be valid as long as you don't configure explicitly what tool-chain and what binaries should be used.

I hope my language sounds not to rude, since you mentioned in your reply:
Quote
This is just a supposition ...
Please accept my apologize if my words are to rough.

Even I think in this case it is more related to the mechanism how Code::Blocks is handling the global variables, every tip is welcome for me. When I searched in the first step for the error-message sorry, unimplemented: 64-bit mode not compiled in in the forum, I already found diverse topics mentioning the same issue were this hint would be leading in the right direction.
Thus thank you for your supposition.



@oBFusCATed

You ask for the exact command used to call Code::Blocks


You asked me to test which nightly is still working as desired and which not:

The only working nightly published after my own build Code::Block that is still completely working with the conf-file content is the following one:

All other nightlies I've tested are not recognizing the global variables associated with the gcc and reset the compiler toolchain executable settings.

In the List "Resolved Fixed" of the nightly "25 April 2021 build (12312)" https://forums.codeblocks.org/index.php/topic,24464.0.html (https://forums.codeblocks.org/index.php/topic,24464.0.html) I found the following comment

Could it be that this way the compiler toolchain executable settings are reset to default values if they contain global variables and not file-names and/or path strings.
But why are the global variables associated with the built-suite not be shown any more?

By the way my Code::Blocks project-file as well as the conf-file I have provided in the zip-file with my post before are now shown as text-files, since forum told me that files with the original attachment could not be posted.
Please undo this change.

Thanks for your support.

Please stay well and healthy,
                                          Eckard Klotz.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: Miguel Gimenez on May 16, 2021, 02:59:45 pm
Quote
compiler: Add proper version comparison to compiler's XML parser (ticket #1041, thanks Miguel Gimenez)

That commit allows enabling options (p.e. -std=c++2a or -std=c++20) depending on compiler version, it does not affect compiler selection or variables.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: oBFusCATed on May 16, 2021, 03:53:55 pm
@eckard_klotz:
Strange...
1. 12286 is working
2. 12312 is broken
3. we don't have night builds in between
4. I don't see anything which might be related.

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.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: eckard_klotz on May 16, 2021, 05:32:42 pm
Hello oBFusCATed


Quote
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.

You are asking me to test more than 20 revisions right?

Usually a build takes half a day on my computer parallel to my work I need at least 20 days or more.
If we would do this discussion in Japanese, I would answer now "chotto....."

However in the meanwhile I found another issue not related to the build-issue but to the conf-file.


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).

We are currently talking about:

the global variable sets
Quote
   <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>


the compiler toolchain executables
Quote
         <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>

the tools-configuration
Quote
   <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>

 
Actually on developer should know this parts of the conf-file and where they are used. I do not.


Even I would be able to tell you exactly with which revision the issue was introduced you still have to check this. So why don't you do it just with the current revision?

Please stay well and healthy,
                                          Eckard Klotz.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: oBFusCATed on May 16, 2021, 05:57:22 pm
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.
You don't have to build the whole workspace. You can only build the core (codeblocks*.cbp).

It is up to you to do it or wait if someone wants to replicate your setup and reproduce this for you.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: eckard_klotz on May 16, 2021, 06:38:11 pm
Hello oBFusCATed.

I will create an official bug-report regarding this. As you already mentioned it is a core feature of Code::Blocks and all users which are working with global variables are potentially affected. What more augments are necessary to  take a look?

Please stay well and healthy,
                                          Eckard Klotz.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: BlueHazzard on May 17, 2021, 01:01:30 am
Hard to believe. Even my old core2quad could build the core stuff in 2-3 minutes.

windows is !significantly! slower then linux when it comes to building codeblocks...
I build codeblocks faster in my linux vm with less cores, then on windows on the same machine (no vm) with all cores of my cpu
My feeling is that gcc is slower on windows and also that our pipe handling is somehow slower, but i never profiled it...
Title: Re: The 11 May 2021 build (12446) is out.
Post by: BlueHazzard on May 17, 2021, 01:10:41 am
@Obfuscated regarding the problem of @eckard_klotz
i think he hits the bug where we kill our config file...

Quote
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...
Title: Re: The 11 May 2021 build (12446) is out.
Post by: oBFusCATed on May 17, 2021, 01:14:17 am
windows is !significantly! slower then linux when it comes to building codeblocks...

This is true, but it is not 200 times slower. GCC is damn slow on windows (and buggy).
I don't know why non of the windows devs haven't stepped up to to provide llvm builds. :)
The dev experience on windows with C::B is something like 2-10x worse compared to the experience on linux.

@Obfuscated regarding the problem of @eckard_klotz
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.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: eckard_klotz on May 17, 2021, 08:03:36 am
Hello oBFusCATed and BlueHazzard

Quote
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.

Yes you are right it happens always.


In my zip-file, you will find in my first post yesterday https://forums.codeblocks.org/index.php/topic,24487.msg167084.html#msg167084 (https://forums.codeblocks.org/index.php/topic,24487.msg167084.html#msg167084) and in my 3rd post yesterday https://forums.codeblocks.org/index.php/topic,24487.msg167094.html#msg167094 (https://forums.codeblocks.org/index.php/topic,24487.msg167094.html#msg167094), I provided screen shots of the associated Code::Blocks dialogs.

The numbers in the names will allow you to differ between the good case and the bad case:

The good case could be shown until the nightly "svn build rev 12286 (2021-01-02 14:06:31) gcc 8.1.0 Windows/unicode - 64 bit".
The bad case could be shown from  the nightly "svn build rev 12312 (2021-04-03 05:14:39) gcc 8.1.0 Windows/unicode - 64 bit" on.

I know that I repeat, what I have already written yesterday. But I hope that this conclusion is helping you to re-produce the issue.

You all payed so much effort in the development and in updating Code::Blocks. I'm especially appreciated that the symbol-browser is working again.
It would be a pity, if this issue would prevent the users of global variables to change to a newer nightly.

Please stay well and healthy,
                                          Eckard Klotz.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: BlueHazzard on May 19, 2021, 12:35:55 am
@eckard_klotz:
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="ask" i get the dialog, and i select your MinGW_9_2_0bit_TDM personality, but in compiler executable settings the global variables are not shown, for me my default config is loaded.
You can check this in the Code::Blocks log tab, the first line: "Loaded config file"

if i use the flag --personality="MinGW_9_2_0bit_TDM" everything works

can you confirm this?

[Edit:] i started a new forum thread for this problem: https://forums.codeblocks.org/index.php/topic,24502
[edit2:] Ticket https://sourceforge.net/p/codeblocks/tickets/1101/
Title: Re: The 11 May 2021 build (12446) is out.
Post by: eckard_klotz on May 19, 2021, 02:14:06 pm
Hello BlueHazzard.

Quote
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...

That sounds good. What ever the reason is, if you could reproduce the result it should be possible to find the rason.


Quote
if i use the flag --personality="MinGW_9_2_0bit_TDM" everything works

can you confirm this?

Yes I can confirm.

Please stay well and healthy,
                                          Eckard Klotz.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: huycan on May 21, 2021, 09:08:20 pm
Does anyone have problem with the Class Wizard? It will hang after filling out all the information of the new class. My system is Windows 10 64-bit.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: oBFusCATed on May 22, 2021, 10:09:27 am
@huycan Is this a new behaviour with this night build? Does it happen with any of the previous ones or 20.03?
Title: Re: The 11 May 2021 build (12446) is out.
Post by: huycan on May 23, 2021, 09:58:43 am
Only this nightly build.
Title: Re: The 11 May 2021 build (12446) is out.
Post by: huycan on May 23, 2021, 10:08:59 am
So far, the newer build 12450 seems to be working fine.... I have to test it more....
Title: Re: The 11 May 2021 build (12446) is out.
Post by: eckard_klotz on May 28, 2021, 10:51:10 am
Dear Developers.

Today I have downloaded the 24 May 2021 build (12452) from https://forums.codeblocks.org/index.php/topic,24510.0.html (https://forums.codeblocks.org/index.php/topic,24510.0.html).
I can confirm that the issue reported by me regarding the --personality="ask" problem is not occurring with the new build.

Thanks for your effort to solve it.

Please stay well and healthy,
                                         Eckard Klotz.