Recent Posts

31

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

32

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

33

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

34

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.

35

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.

36

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.

37

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.

38

Help / Re: Stripping debug info from output tree

« Last post by stahta01 on March 09, 2025, 07:45:23 pm »

You cannot expect a batch file to work using an bash/sh shell! Change the shell or edit the batch file to work.

 Tim S.

39

Help / Re: Stripping debug info from output tree

« Last post by wtfisgoingoff on March 09, 2025, 03:47:09 am »

Using an MSYS2 UCRT64 bash shell on my Windows 10 setup, I see that I have:

$ where strip
C:\msys64\ucrt64\bin\strip.exe
C:\msys64\usr\bin\strip.exe
$ pacman -Qo /ucrt64/bin/strip.exe
/ucrt64/bin/strip.exe is owned by mingw-w64-ucrt-x86_64-binutils 2.44-1
$ pacman -Qo /usr/bin/strip.exe
/usr/bin/strip.exe is owned by binutils 2.44-1

If you feed tentative shell commands through something like

$(TARGET_COMPILER_DIR)..\usr\bin\env MSYSTEM=UCRT64 CHERE_INVOKING=1 /usr/bin/bash -lc

you can let MSYS2 find the best version to use. In the above instance, it will use an /ucrt64/bin version if exists; otherwise it will look for what essentially is a Cygwin based version in /usr/bin. If that also fails, it will then look for a system version.

$ where xcopy
C:\Windows\System32\xcopy.exe

Unfortunately, syntax for Windows xcopy is:

xcopy <Source> [<Destination>] [/w] [/p] [/c] [/v] [/q] [/f] [/l] [/g] [/d [:MM-DD-YYYY]]   [/s [/e]] [/t] [/k] [/r] [/h] [{/a | /m}] [/n] [/o] [/x] [/exclude:FileName1[+[FileName2]][+[FileName3]]] [{/y | /-y}] [/z]  [/j] [/compress]

Note, all options come after file specifiers, not before! It's easy enough to make a version of things with the xcopy options flipped to after all file specifiers. These command files like never change.

I got 4 strip.exe
D:\MSYS2\usr\bin\strip.exe
D:\MSYS2\ucrt64\bin\strip.exe
D:\MSYS2\ucrt64\x86_64-w64-mingw32\bin\strip.exe
D:\MSYS2\usr\x86_64-pc-msys\bin\strip.exe
This one [D:\MSYS2\usr\x86_64-pc-msys\bin\strip.exe] didn't show those
'output32_64\*.exe': No such file   'output32_64\*.dll': No such file   'output32_64\share\CodeBlocks\plugins\*.dll': No such file   

But none stripping was done. Every file should be stripping  is  still very large.

40

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

« Last post by Pecan on March 09, 2025, 12:54:13 am »

I have prepared and attached simple demo. Created it from wxwidgets template project. You must change compiler settings, linker settings and search directories in debug mode to your own because I have wxwidgets installation in custom home directory. Problematic variables are: mListCtrlSources and thisNOTwork (I already started they with -> )

Thanks for the example code.
I have verified that the legacy CodeCompletion plugin will not produce completion choices for the code you indicated.

Code

    wxStaticBoxSizer * staticBoxSource = new wxStaticBoxSizer(wxHORIZONTAL, this, "Source dirs && files");
    wxListCtrl* mListCtrlSources = new wxListCtrl(this, -1);
    mListCtrlSources->

... and others ..

In order to produce completions for your code, you will have to use the Clangd_client plugin instead.

Info:
The instuctions for using the Clangd_client language server protocol (LSP):
https://wiki.codeblocks.org/index.php/CB_Clangd_Client

If clangd is already installed on your Linux system, you need only disable the CodeCompletion plugin, enable the Clangd_client plugin, and restart CodeBlocks.

Go to the Settings/Clangd_client/ and enter the address of your Clang executable.