The 24 March 2024 build (13493) is out.

[killerbot]

We switched to gcc 13.1.0 (on 04 June 2023) --> download the new wx/mingw dll's see link below

Get the compiler we use here : https://github.com/brechtsanders/winlibs_mingw/releases/download/13.1.0-16.0.5-11.0.0-ucrt-r5/winlibs-x86_64-posix-seh-gcc-13.1.0-mingw-w64ucrt-11.0.0-r5.7z

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.

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


The 24 March 2024 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2024/CB_20240324_rev13493_win64.7z
  - Linux :
   none

The current SDK version is : 2.25.0

Resolved Fixed:

• Autorevision: fix git log query (ticket #1462, thanks kipade).
• Clangd_client 1.2.115 24/03/22 Support for clangd v18 additional "fixes available" and fix to avoiding duplicate responses. Thanks Christo.

Regressions/Confirmed/Annoying/Common bugs:

[Xaviou]

Hi.

OS X version of this rev can be downloaded from my website.
There is only a macOS-11.6 version.
Note that it is not a notarized version of the application.

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

Debian Bookworm and Bullseye (32 and 64 bits) can be installed from my repo
The corresponding unsigned deb files can also be downloaded from the website page linked above.

Ubuntu-22.04 and 23.10 versions can be installed from my ppa

Regards
Xav'

[nenin]

Error detected: when I tried to compile single file, does not matter through menu, tree or hot key, C::B tries to run library instead of compile it.
Win 10 64b.

[eckard_klotz]

Hello Everybody.

It seems that this issue is the same as described in the following ticket:
https://sourceforge.net/p/codeblocks/tickets/1467/.

I face temporarily a similar issue while building a single file. However by investigating the error-Output of Code::Blocks I came to the same conclusion as Miguel Gimenez:

• The initial root cause is crash of the compiler.
• MinGW 13.2.0 UCRT 64 published by MSYS2.
• running on Windows 10.

[100.0%] x86_64-w64-mingw32-g++.exe -Wnon-virtual-dtor -Wshadow -Winit-self -Wredundant-decls -Wcast-align -Wundef -Wfloat-equal -Winline -Wunreachable-code -Wmissing-declarations -Wmissing-include-dirs -Wswitch-enum -Wswitch-default -Weffc++ -Wzero-as-null-pointer-constant -Wmain -pedantic-errors -pedantic -Wextra -Wall -std=c++14 -pipe -mthreads -isystem C:\Lib\wxWidgets\3_2_4\include -isystem ..\..\..\sources\tinyxml -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -fomit-frame-pointer -fexpensive-optimizations -O3 -IC:\Lib\wxWidgets\3_2_4\include -I..\..\..\sources\KanjiNoKenkyuu -I..\..\..\sources\tinyxml -I..\..\..\sources\analysis -I..\..\..\sources\dataBase -I..\..\..\sources\view -I..\..\..\sources\view\symbol -I..\..\..\sources\view\tree -I..\..\..\sources\view\logging -I..\..\..\sources\view\dialogue -I..\..\..\sources\view\pictograph -I..\..\..\sources\view\pictograph\draw -I..\..\..\sources\view\description -I..\..\..\sources\dataBase\command -I..\..\..\sources\dataBase\symbol -I..\..\..\sources\dataBase\symbol\command -I..\..\..\sources\dataBase\description -I..\..\..\sources\dataBase\description\command -I..\..\..\sources\dataBase\pictograph -I..\..\..\sources\dataBase\pictograph\command -I..\..\..\sources\dataBase\association -I..\..\..\sources\dataBase\association\command -I..\..\..\sources\dataBase\template -I..\..\..\sources\dataBase\template\command -I..\..\..\sources\dataBase\label -I..\..\..\sources\dataBase\label\command -I..\..\..\sources\dataBase\font -I..\..\..\sources\dataBase\font\command -c C:\Project\Nihongo_Shiryou\SandBox\trunk\sources\view\dialogue\fnt_Dlg_FontCharacter.cpp -o obj\Release\sources\view\dialogue\fnt_Dlg_FontCharacter.o
In file included from C:/Tool/Development/MinGW/MinGW_13_2_0_MSYS/ucrt64/lib/gcc/x86_64-w64-mingw32/13.2.0/include/immintrin.h:104,
                 from C:/Tool/Development/MinGW/MinGW_13_2_0_MSYS/ucrt64/lib/gcc/x86_64-w64-mingw32/13.2.0/include/x86intrin.h:32,
                 from C:/Tool/Development/MinGW/MinGW_13_2_0_MSYS/ucrt64/include/winnt.h:1658,
                 from C:/Tool/Development/MinGW/MinGW_13_2_0_MSYS/ucrt64/include/minwindef.h:163,
                 from C:/Tool/Development/MinGW/MinGW_13_2_0_MSYS/ucrt64/include/windef.h:9,
                 from C:/Tool/Development/MinGW/MinGW_13_2_0_MSYS/ucrt64/include/windows.h:69,
                 from C:/Tool/Development/MinGW/MinGW_13_2_0_MSYS/ucrt64/include/winsock2.h:23,
                 from C:\Lib\wxWidgets\3_2_4\include/wx/msw/wrapwin.h:46,
                 from C:\Lib\wxWidgets\3_2_4\include/wx/atomic.h:45,
                 from C:\Lib\wxWidgets\3_2_4\include/wx/sharedptr.h:14,
                 from C:\Lib\wxWidgets\3_2_4\include/wx/dialog.h:16,
                 from C:\Lib\wxWidgets\3_2_4\include/wx/msgdlg.h:18,
                 from C:\Project\Nihongo_Shiryou\SandBox\trunk\sources\view\dialogue\user_out.h:20,
                 from C:\Project\Nihongo_Shiryou\SandBox\trunk\sources\view\dialogue\fnt_Dlg_FontCharacter.cpp:22:
C:/Tool/Development/MinGW/MinGW_13_2_0_MSYS/ucrt64/lib/gcc/x86_64-w64-mingw32/13.2.0/include/avx512fp16vlintrin.h:753:1: internal compiler error: Segmentation fault
  753 | }
      | ^
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using -freport-bug).
See <https://github.com/msys2/MINGW-packages/issues> for instructions.
Process terminated with status 1 (0 minute(s), 25 second(s))
1 error(s), 0 warning(s) (0 minute(s), 25 second(s))

You see in the lower part compiler-output mentioning a internal compiler error: Segmentation fautl. And the statement libbacktrace could not find executable to open does not means that Code::Blocks tries to start the lib created by building the single source. It means that a library used by the build-tool was not available.

This happens not with every build. Even I start the build again for a file where the build crashed before it succeeds with the next build.

What is irritating is the fact that the first part of the error-output is mentioning an error in the included headers what is misleading you if you don't recognize  that this is actually an issue of the compiler itself.

Even I agree that this is actually not caused by Code::Blocks, I wonder what has changed while the nightly 13456 (06.03.2024) and the nightly 13493 (24.06.2024) since I frequently used this build-suite 27.02.2024 for single file builds as well as for project builds and until the 13493 (24.06.2024)  I never faced this issue and I have not modified my build configuration.

I wish you all happy Eastern,
                                           Eckard Klotz.

[Miguel Gimenez]

Ticket #1467 does not describe anything, so it is difficult to say if it is the same issue. I suggest removing your post from that closed ticket and creating a new  one.

I do not see any commit in the given range related to compiing, if the call to the compiler has not changed this may indicate a memory exhaustion.

[eckard_klotz]

Hello Miguel Gimenez.

Actually I just wanted to support the discussion started by Nenin and Penny Mathenjwa with some details I have observed after changing to this nightly in the hope that they will confirm that this is what they have observed.

However this is nothing I would report as an issue by myself, since it happens not often enough. As long as Nenin and Penny Mathenjwa will not continue their discussion with adding more details about what they have actually faced, I will not bother you with this any more.

Best regards,
                    Eckard.

[vatsaladitya]

I face temporarily a similar issue while building a single file. However by investigating the error-Output of Code::Blocks I came to the same conclusion as Miguel Gimenez:

• The initial root cause is crash of the compiler.
• MinGW 13.2.0 UCRT 64 published by MSYS2.
• running on Windows 10.

This may really be the problem with the compiler itself. I am using MinGW w64 MSVCRT (GCC 13.2.0) build from winlibs.com and there seems to be no issue compiling single files.

[stahta01]

I face temporarily a similar issue while building a single file. However by investigating the error-Output of Code::Blocks I came to the same conclusion as Miguel Gimenez:

• The initial root cause is crash of the compiler.
• MinGW 13.2.0 UCRT 64 published by MSYS2.
• running on Windows 10.

This may really be the problem with the compiler itself. I am using MinGW w64 MSVCRT (GCC 13.2.0) build from winlibs.com and there seems to be no issue compiling single files.

It might be a UCRT bug; I get weird issues from time to time using UCRT, so, I tend to see if the problem happens under MSYS2 MINGW64 which uses MSVCRT.

Tim S.

[nenin]

To make things more complicated: I found that issue appeared with "static lib" project, not "exe". I`m not sure it is related to compiler. 

[eckard_klotz]

Hello Nenin.

Since you don't provide screenshots or tool-outputs but assumptions only, it is not really possible to give you a hint.

Forced by your initial report in this forum-topic I have tried it out in my project and provided the Code::Blocks output.

• The output already provides the information needed to decide that the compiler has a problem and not Code::Blocks.
• Thus it sounds plausible for me to search for a resolution for the build-suite and not for Code::Blocks

Currently we know from your issue:

• You work with Windows 10.
• You try to build a single source file.
• You assume that Code::Blocks tries to run a staic library.
• Did I forget something???

Until we don't know:

• What is your build suite (compiler tool-chain) ?
• What is the Code::Blocks build-output ?

Your assumption that Code::Blocks tries to run your static library sounds not plausible, since a static library contains no executable ready to run but a collection of functions only. In the case you use a GNU compiler the static library is actually only an archive (similar to a zip-file) that contains the object-files of your compiled sources but no linker-result. This files are not ready to run anyway.

How do you come to your statement

when I tried to compile single file, does not matter through menu, tree or hot key, C::B tries to run library instead of compile it.

Code::Blocks usually outputs the command-line of every binary called while building in the build log. Why don't you post it, as I have done? This would give us the chance to figure out what really happened instead of wondering about your assumptions.

Best regards,
                   Eckard.

[nenin]

I cannot reproduce it, sorry.
There where no any build logs, just this dialog jumped out.

[eckard_klotz]

Hello Nenin.

Could it be that you have used in the application-menu "Build" by accident the option "Run" (Ctrl-F10) or the option "Build and run"(F9) instead of the option "Compile current file" (Ctrl-Shift-F9)?

Best regards,
                    Eckard

[nenin]

Hello Nenin.

Could it be that you have used in the application-menu "Build" by accident the option "Run" (Ctrl-F10) or the option "Build and run"(F9) instead of the option "Compile current file" (Ctrl-Shift-F9)?

Best regards,
                    Eckard

Hi, no. I was really surprised and tries both 3 single-file compile options: main menu "Compile current file", hotkey Ctrl-Shift-F9 and "Build file" from the project tree.  One additional thing should be noted: project was old, untouched for c.a. 10 years.

[blauzahn]

@Nenin: I see a similar popup sometimes. If I remember correctly, It is when I have a workspace with at least 2 projects and the selected Target is from project A but the currently selected project is B and does not have that target and you trigger compilation. This happens, e.g. when you touch the project-file externally (e.g. a reset in VCS) and codeblocks reloads that project(s). The target list isn't updated always to the correct project within the workspace. This is IMHO a bug in cb.

[nenin]

@Nenin: I see a similar popup sometimes. If I remember correctly, It is when I have a workspace with at least 2 projects and the selected Target is from project A but the currently selected project is B ****.

This is possible, I tried to refactor old soft which also use a dozen of the small custom libs. I faced such glitch for the first time and was brutally surprised.