The 04 June 2023 build (13311) 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_wx3221_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 04 June 2023 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2023/CB_20230604_rev13311_win64.7z
  - Linux :
   none

The current SDK version is : 2.24.0

Resolved Fixed:

• fixed compiler detection of MinGW as supplied by installer is not working
• make wxSmithDemo and wxSmithSTC compile on later wx versions
• allow to manage Globs also via pop-up menu in project explorer

Regressions/Confirmed/Annoying/Common bugs:

[killerbot]

compared to yesterdays nightly:

• again new compiler, now again POSIX based
• download the supportive dll's  (wx and mingw)

[nenin]

compared to yesterdays nightly:

• again new compiler, now again POSIX based
• download the supportive dll's  (wx and mingw)

Thanks, it is big step forward! And "svn13311" looks beautiful.

[Neo]

Maybe clangd plugin is broken; it reports unrealistic 'errors'. See attached screenshot.

EDIT:
It seems clangd plugin conflicts with MSYS2 clangd (mingw-w64-clang-i686-clang-tools-extra). I switched back to winlibs clangd and it works like before.

[nenin]

I observed strange thing:
path in CB console when fresh built file is executed:

Code

Set variable: PATH=.;C:\mingw64\nixman13_1w32u\bin;C:\mingw64\nixman13_1w32u;C:\mingw64\nixman12_2w32u\bin;C:\mingw64\nixman12_2w32u;C:\ProgramData\Oracle\Java\javapath;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files (x86)\Microsoft SQL Server\80\Tools\Binn;C:\Program Files\Microsoft SQL Server\110\Tools\Binn;C:\Program Files (x86)\Common Files\AspenTech Shared;C:\Windows\System32\OpenSSH;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\CryptoTech\CryptoCard;C:\Program Files (x86)\CryptoTech\CryptoCard;C:\Program Files\Wolfram Research\WolframScript;C:\Users\*****\AppData\Local\Microsoft\WindowsApps;c:\mingw64\nixman12_2w32u\bin

actual path, from cmd:

Code

PATH=C:\ProgramData\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Microsoft SQL Server\80\Tools\Binn\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\Common Files\AspenTech Shared\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\CryptoTech\CryptoCard\;C:\Program Files (x86)\CryptoTech\CryptoCard\;C:\Program Files\Wolfram Research\WolframScript\;C:\Users\****\AppData\Local\Microsoft\WindowsApps;c:\mingw64\nixman12_2w32u\\bin

project actually is using "C:\mingw64\nixman13_1w32u"

[flycat]

Every time I use File->New->Class , Then click Create , click "add to project" Yes, the program will not respond.
This problem has existed for many years, is it only I encountered?
20.03 Works fine
The system is Windows 10 22H2

[Miguel Gimenez]

This issue is described on ticket 1393.

[Khram]

Quite often it crashes and freezes if GCC-3.4.4 compiler errors occur

[Pecan]

Maybe clangd plugin is broken; it reports unrealistic 'errors'. See attached screenshot.

EDIT:
It seems clangd plugin conflicts with MSYS2 clangd (mingw-w64-clang-i686-clang-tools-extra). I switched back to winlibs clangd and it works like before.

You cannot mix a clang compiler with a clangd Mingw process or vice versa.
Both must be clang or Mingw.
Check your clangd setings at Settings>Editor>Clangd>C/C++Parser>SpecifyClangdExecutableToUse.

Also see the explanation at https://wiki.codeblocks.org/index.php/CB_Clangd_Client and seach for the keywords "Dont't mix".

[Neo]

Maybe clangd plugin is broken; it reports unrealistic 'errors'. See attached screenshot.

EDIT:
It seems clangd plugin conflicts with MSYS2 clangd (mingw-w64-clang-i686-clang-tools-extra). I switched back to winlibs clangd and it works like before.

You cannot mix a clang compiler with a clangd Mingw process or vice versa.
Both must be clang or Mingw.
Check your clangd setings at Settings>Editor>Clangd>C/C++Parser>SpecifyClangdExecutableToUse.

Also see the explanation at https://wiki.codeblocks.org/index.php/CB_Clangd_Client and seach for the keywords "Dont't mix".

I am not sure if I can understand what the wiki says. But the 'don't mix' rule is not always true.

clangd plugin:
C:\apps\gnu\winlibs\mingw32\bin\clangd.exe

I tried `C:\apps\gnu\MSYS64\mingw32` or `C:\apps\gnu\MSYS64\mingw64` and both work with clangd.

[cbuser1]

Every time I use File->New->Class , Then click Create , click "add to project" Yes, the program will not respond.
This problem has existed for many years, is it only I encountered?
20.03 Works fine
The system is Windows 10 22H2

I've had this issue as well on windows 7. Unfortunately I got busy and couldn't test thoroughly the nightlies to see which which was the last nightly without this problem. The last time I posted I was on nightly CB_20210709_rev12487_win64.7z which I have yet to see freeze.
But from the changelog it wasn't obvious what has changed exactly that would cause this issue  to occur in the nightly that came after that.

[UberNewb2]

Between 13215 and 13311 a change was made in the shift tab behavior. It now moves left in the tabs of open files, instead of un-indenting one tab stop. I *really* miss that.

[myztmy]

Resolved Fixed:

• fixed compiler detection of MinGW as supplied by installer is not working

Regressions/Confirmed/Annoying/Common bugs:

Yes, it can detect compiler  in my  MinGW64  directory now , but the compiler is judged as "GNU GCC Compiler" ,  not exactly as "GNU GCC MinGW64 Compiler" . Although this may not be relevant, the compiler still works normally,  but I can't stand it, just because I'm am a perfectionist ,virgo.

P.S.  Now that  every  nightly builds  C::B needs the other two files of the corresponding version  to run,  and  most easiest way is to unzip both of them into the same directory where you unzipped the nightly  , why not pack them together into a file,
Let's download once and unzip once  instead of  download three times and unzip three times .

Regards

[jeRRy]

Between 13215 and 13311 a change was made in the shift tab behavior. It now moves left in the tabs of open files, instead of un-indenting one tab stop. I *really* miss that.

For Windows, you can try renaming (or deleting) the File "default.cbKeyBinder20.conf" in "C:\Users\username\AppData\Roaming\CodeBlocks".

That works for me.

[UberNewb2]

Between 13215 and 13311 a change was made in the shift tab behavior. It now moves left in the tabs of open files, instead of un-indenting one tab stop. I *really* miss that.

For Windows, you can try renaming (or deleting) the File "default.cbKeyBinder20.conf" in "C:\Users\username\AppData\Roaming\CodeBlocks".

That works for me.

Ah thank you very much, that solved it. Closed CB, deleted the file, restarted, and it resumed the old behavior. You're awesome.