User forums > Nightly builds
The 11 May 2021 build (12446) is out.
eckard_klotz:
Hello oBFusCATed and gd_on
Thanks for your fast response
@gd_on
You wonder why I have changed the called binary.
* But the answer is I haven't changed it.
* Code::Blocks has done the change by ignoring the content of the conf-file used with the personality chosen wile calling it.
* If you would take a look to the zip-file, I have provided with my first post, you will see 2 images with the version-number 12240 in the name, which show you, what I have configured and how the global variables should be used to define the compiler toolchain executables.
* The images version-number 12446 in the name show you how my configuration was changed or better ignored and reset by the current nightly. Fortunately this changes was not stored in the conf-file. Thus I could still use my configuration with my old self-build Code::Blocks 1240 from last December.
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.
* But If I set up global variables in Code::Blocks for everything and configure the use of this global variables in the compiler toolchain executable settings, I actually expect that Code::Blocks is using my configuration and is not trying to search the tools by itself.
* And if this has worked in the past I actually expect that that this will also work in the newer versions.
I hope my language sounds not to rude, since you mentioned in your reply:
--- Quote ---This is just a supposition ...
--- End quote ---
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
* I call Code::Blocks with a shortcut that uses the following destination.
* C:\Tool\Development\CodeBlocks\Nightlies\2021_05_11\bin\codeblocks.exe --personality="ask"
* 2021_05_11 depends on the nightly I use. If I change it, I change the corresponding working-path of the shortcut also.
* --personality="ask" provides me a list of different conf-files for different build-suites. (I attached a screen shot)
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:
* svn build rev 12286 (2021-01-02 14:06:31) gcc 8.1.0 Windows/unicode - 64 bit
All other nightlies I've tested are not recognizing the global variables associated with the gcc and reset the compiler toolchain executable settings.
* svn build rev 12312 (2021-04-03 05:14:39) gcc 8.1.0 Windows/unicode - 64 bit
* svn build rev 12315 (2021-04-30 18:28:46) gcc 8.1.0 Windows/unicode - 64 bit
* svn build rev 12446 (2021-05-09 12:52:18) gcc 8.1.0 Windows/unicode - 64 bit
In the List "Resolved Fixed" of the nightly "25 April 2021 build (12312)" https://forums.codeblocks.org/index.php/topic,24464.0.html I found the following comment
* compiler: Add proper version comparison to compiler's XML parser (ticket #1041, thanks Miguel Gimenez)
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.
* I have exchanged the dot before the actually file attachment by an underscore.
* In addition I added the new file-attachment .txt.
* KanjiNoKenkyuu.cbp became KanjiNoKenkyuu_cbp.txt.
* MinGW_9_2_0_64bit_TDM.conf became MinGW_9_2_0_64bit_TDM_conf.txt.Please undo this change.
Thanks for your support.
Please stay well and healthy,
Eckard Klotz.
Miguel Gimenez:
--- Quote ---compiler: Add proper version comparison to compiler's XML parser (ticket #1041, thanks Miguel Gimenez)
--- End quote ---
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.
oBFusCATed:
@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.
eckard_klotz:
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.
--- End quote ---
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 configured in the menu Tools (not Tools+) an item to open the project-folder (attached image "CB_12240_Tool_OpenProjectFolder.png")
* In the current nightly opened with the conf-file created with the older Code::Blocks version this Tool menu item is not visible any more as well as its configuration i (attached image "CB_12446_Tool_OpenProjectFolder.png")
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>
--- End quote ---
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>
--- End quote ---
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>
--- End quote ---
Actually on developer should know this parts of the conf-file and where they are used. I do not.
* I provided you images which show the good case as well as the bad cases. Thus my report should be reproduce able.
* Once you see the same effect wile using my conf-file you just have to figure out where the corresponding xml nodes in the conf-file are processed.
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.
oBFusCATed:
--- Quote from: eckard_klotz on May 16, 2021, 05:32:42 pm ---You are asking me to test more than 20 revisions right?
--- End quote ---
More like lg2(20), if you use binary search.
--- Quote from: eckard_klotz on May 16, 2021, 05:32:42 pm ---Usually a build takes half a day on my computer parallel to my work I need at least 20 days or more.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version