Recent Posts

31

Development / An assertion when opening a workspace

« Last post by LETARTARE on March 11, 2025, 03:10:19 pm »

Context: Leap-15.6, wx-326-14, gcc-13.3.0, Cb-13626

When CB is started, if one or more projects have been deleted or moved, an assertion is generated which opens a dialog providing information

So I proposed a fix: https://sourceforge.net/p/codeblocks/tickets/1516/

32

Nightly builds / Re: The 22 February 2025 build (13620) is out.

« Last post by raynebc on March 11, 2025, 08:08:03 am »

I've found that the "Remove all" function in the Breakpoints window doesn't work unless any of the files containing an existing breakpoint are currently open.

33

Help / Re: Code completion doesn't show up for some wxWidgets

« Last post by Pecan on March 11, 2025, 05:52:01 am »

@ Dibo
What version of CodeBlocks are you running.

Did you build it yourself? If so, did you also build the any of the plugins in the Contrib workspace?

34

Help / Re: Code completion doesn't show up for some wxWidgets

« Last post by Dibo on March 10, 2025, 09:23:49 pm »

Hmm, but in plugins manager I don't have anything like clangd (see attachment). When I click on "Install new" I have file browser filtered by .cbplugin, not .so or executable. Wiki from your link doesn't say anything about cbplugin installation, it expects that clangd plugin already exists and anything what must be done is just enable it
And seems that I have it installed on my linux:

Code

locate clangd

/usr/bin/clangd
/usr/bin/clangd-18
/usr/lib/llvm-18/bin/clangd

Edit: Note that I already have installed codeblocks, codeblocks-common and codeblocks-contrib packages

35

Plugins development / cb-ClangTidy plugin to use clang-tidy within Code::Blocks

« Last post by christo on March 10, 2025, 06:00:11 pm »

New plugin to run clang-tidy within C::B is available in github repository cb-ClangTidy
It's derived from CppCheck plugin and follows similar flow. Description is available in README.md
Tested only on Linux wx3.2

Thanks
Christo

36

Using Code::Blocks / Re: Generation with Pelles C Compiler (Version 12.00.1) failed

« Last post by ThierryD on March 10, 2025, 04:28:56 pm »

Patch available to Pelles C Forum. Work fine (despite of my antivirus that detect "thread" into executable generated by Pelles C !!!).

37

Help / Re: Stripping debug info from output tree

« Last post by everSome on March 10, 2025, 02:37:03 pm »

I forgot to mention that you'll have to uncomment three commands beginning at line 241:

REM %3 "%CB_OUTPUT_DIR%/*.exe"
REM %3 "%CB_OUTPUT_DIR%/*.dll"
REM %3 "%CB_OUTPUT_RESDIR_STRIP%/plugins/*.dll"

just remove the leading "REM " characters thereof as I do not want them stripped for my personal use.

38

Help / Re: Stripping debug info from output tree

« Last post by everSome on March 10, 2025, 02:16:21 pm »

You are welcome to try what I use to see if that helps you. Note that I only have a standard MSYS2 environment on my Windows 10 machine. Place these scripts in the src directory where update.bat resides. From a UCRT64 shell execute

./update32_64_MSYS2.sh
or
./update31_64_MSYS2.sh

in stead of

update32_64.bat
or
update31_64.bat

as desired.
Note that attached version of update.bat is meant to replace the existing version thereof. Oops, I'm only allowed 2 attachments, and I had to tack on .txt name suffixes which you'll have to remove.

39

Help / Re: Stripping debug info from output tree

« Last post by stahta01 on March 10, 2025, 06:27:24 am »

FYI, under MSYS2's Porting documentation: You may need to use platform checks to switch between behaviour suited for MSYS2 and the default one. Some useful identifiers:

Identifier          Platform(s)                Usage
_WIN32              mingw, msvc                C code (#ifdef ...)
_WIN64              64-bit mingw, 64-bit msvc  C code (#ifdef ...)
__CYGWIN__          msys2, cygwin              C code (#ifdef ...)
__MSYS__            msys2                      C code (#ifdef ...)
x86_64-pc-msys2     64-bit msys2               Build scripts (if [ $host = '...' ])
i686-pc-msys2       32-bit msys2               Build scripts (if [ $host = '...' ])
x86_64-w64-mingw32  64-bit mingw               Build scripts (if [ $host = '...' ])
i686-w64-mingw32    32-bit mingw               Build scripts (if [ $host = '...' ])
cygwin              msys2                      Python (sys.platform)
win32               mingw                      Python (sys.platform)

from which I'd guess that the x86_64-w64-mingw32 versions are there to help cross compiling build scripts. Now my understanding of MSYS2 bash is that while it will handle .sh and .bash scripts, .bat scripts are just passed to Windows cmd.exe which can find xcopy, but does not have a native version of strip or zip. You could parameterize update.bat's usage of them and use it via a .sh script that through 2 additional arguments tells cmd.exe where to find them (which is what I've done), or you might copy C:\msys64\ucrt64\bin\strip.exe and C:\msys64\usr\bin\zip.exe into the C:\Windows\System32\ folder so that cmd.exe can naturally find them.

MSys2 does not pass .bat files to an cmd.exe command.

Tim S.

40

Help / Re: Stripping debug info from output tree

« Last post by everSome on March 10, 2025, 04:09:46 am »

FYI, under MSYS2's Porting documentation: You may need to use platform checks to switch between behaviour suited for MSYS2 and the default one. Some useful identifiers:

Identifier          Platform(s)                Usage
_WIN32              mingw, msvc                C code (#ifdef ...)
_WIN64              64-bit mingw, 64-bit msvc  C code (#ifdef ...)
__CYGWIN__          msys2, cygwin              C code (#ifdef ...)
__MSYS__            msys2                      C code (#ifdef ...)
x86_64-pc-msys2     64-bit msys2               Build scripts (if [ $host = '...' ])
i686-pc-msys2       32-bit msys2               Build scripts (if [ $host = '...' ])
x86_64-w64-mingw32  64-bit mingw               Build scripts (if [ $host = '...' ])
i686-w64-mingw32    32-bit mingw               Build scripts (if [ $host = '...' ])
cygwin              msys2                      Python (sys.platform)
win32               mingw                      Python (sys.platform)

from which I'd guess that the x86_64-w64-mingw32 versions are there to help cross compiling build scripts. Now my understanding of MSYS2 bash is that while it will handle .sh and .bash scripts, .bat scripts are just passed to Windows cmd.exe which can find xcopy, but does not have a native version of strip or zip. You could parameterize update.bat's usage of them and use it via a .sh script that through 2 additional arguments tells cmd.exe where to find them (which is what I've done), or you might copy C:\msys64\ucrt64\bin\strip.exe and C:\msys64\usr\bin\zip.exe into the C:\Windows\System32\ folder so that cmd.exe can naturally find them.