Recent Posts

Pages: 1 2 3 4 5 [6] 7 8 9 10
51
Development / Re: Mostly Successful Build CB 25 on GhostBSD 25
« Last post by shinhaha on January 22, 2026, 03:53:42 am »
OK so I had a day spare and a laptop spare which I've just installed GhostBSD 25 onto so thought I'd try and build Code::Blocks 25.03.  Specifically I have GhostBSD 25.02-R14.3p2 and while it does have Code::Blocks 20 available in its package repository I wanted something newer.

I didn't do a full build log but half-way through I thought I'd write some notes in case anyone else wanted to do this too.sled rider

Set up the build environment

Need to install the autotools and development tools (I wasn't sure exactly which packages so I just installed all the dev tools which is probably excessive).  Note that installing "gcc" will bring in GCC version 13 which will fail to compile because it complains about precompiled headers so I had to remove that and use "gcc15".  I think these are all the packages you will need from a fresh install (as root/sudo):
Code
pkg install autotools
pkg install -g 'GhostBSD*-dev'
pkg remove gcc13
pkg install gcc15

Now its necessary to build wx32-gtk from the Ports tree (I don't think the one available as a package has the config tool but maybe it does and this step is not necessary?)
Code
pkg install ports
cd /usr/ports/x11-toolkits/wxgtk32
sudo make
sudo make install

Finally add a symlink in /usr/local/bin so wx-config points to the right place:
Code
sudo ln -s /usr/local/bin/wxgtk3u-3.2-config /usr/local/bin/wx-config

That should be enough to get the build environment set up and now you can follow the build instructions (i.e., ./bootstrap then ./configure, etc.,) in the CB README, however, the build will fail because of an issue around fontconfig.h not being found and also because the linker can't find the correct location of the kvm libraries.  As far as I can tell this is because GhostBSD (perhaps also other BSDs) keep these in a slightly different location (i.e., /lib instead of /usr/lib for kvm).  I managed to get around these issues in a slightly kludgy way but it did work.

fontconfig.h
I found out after I'd done this that there is a post about this on the forum which is probably a better solution and it would probably be better to modify the Makefile include path, however, I was impatient to carry on building so I simply changed the source file in:

src/plugins/contrib/source_exporter/wxPdfDocument/src/pdffontmanager.cpp

so that the included file was the full path: "/usr/local/include/fontconfig/fontconfig.h"

kvm
I get an error from the linker when building clangd_client so I changed the Makefile in:

src/plugins/contrib/clangd_client so that WX_LIBS has the flags "-L/lib -lkvm":

Code
WX_LIBS = -L/lib -lkvm -L/usr/local/lib ....etc...

And doing all that got me a mostly working build of Code::Blocks...at least as far as I can tell it works, I haven't done any in-depth testing yet but will do that soon.  I say "mostly" working because a couple of the toolbars appear to have missing icons (also in GhostBSD which is using MATE changing the toolbar icon size doesn't actually change the size of the buttons, just the size of the graphics within the buttons).

I'll attach a screenshot if anyone has any suggestions as to where the icons have gone?
haha, i like it!
52
This approach seems like a step in the right direction. A brainrot games unified workspace would definitely streamline the development process, especially for handling different wxWidgets versions under Windows.
so fun!
53
Help / Re: code::blocks hangs at startup
« Last post by stahta01 on January 22, 2026, 12:28:16 am »
Patch for my wild guess at the cause, could be multiple causes since wxSmith was written for old wxWidgets version. Edit: My wild guess is that the png files are old enough to break something.

Deleted outdated patch code

Tim S.
54
It seems CodeBlocks aims for the upper limit which is 32767, in
  • src/plugins/compilergcc/directcommands.cpp
  • src/plugins/contrib/clangd_client/src/LSPclient/client.cpp
which is not entirely true on windows because in some cases it can go down to as low as 8191.

I've experienced this annoying bug while trying to build a big project where CodeBlocks had correctly detected that the initial command was over the 32k limit but the reduced command with the trailing response file would still fail with "Command line is too big" error from the system.

Attached is a simple patch to address this issue.

(I tested compiler.dll with these new values and my project can finally build!)
55
Help / Re: code::blocks hangs at startup
« Last post by Miguel Gimenez on January 21, 2026, 03:56:41 pm »
Can you put a breakpoint in OnAttach() and check where it hangs?
56
Help / Re: code::blocks hangs at startup
« Last post by killerbot on January 21, 2026, 03:52:05 pm »
the wxwidgets I used is : 3.2.8

I updated with your latest commit, the problem is still there.

fyi: my gdk-pixbug version is 2.44.4
57
Help / Re: code::blocks hangs at startup
« Last post by Miguel Gimenez on January 21, 2026, 03:48:13 pm »
Replaced XPM with PNG in OnAttach(), see r13773, this may fix the issue (untested).

There are more XPM bitmaps in other parts.
58
Help / Re: code::blocks hangs at startup
« Last post by Miguel Gimenez on January 21, 2026, 01:44:53 pm »
On 2.43 gdk-pixbuf deprecated the XPM api and disabled XPM loader by default, see release notes.

wxSmith defines a XPM in wxSmith.cpp:50 and uses it during plugin attachment in wxSmith.cpp:211; Probably changing this XPM to a PNG or SVG fixes the issue.
59
Help / Re: code::blocks hangs at startup
« Last post by Miguel Gimenez on January 21, 2026, 11:44:33 am »
Works OK on Ubuntu 22.04 with wxWidgets 3.2.6, I cannot check on other Linux. wxSmith uses some initialization tricks that may be non-portable.

This ticket reports that downgrading gdk-pixbuf2 from 2.44.2-1 to 2.42.12-2 fixes the problem.
60
Help / Re: code::blocks hangs at startup
« Last post by stahta01 on January 21, 2026, 11:36:16 am »
2 days ago, since a very long time, I did a fresh build of CB on linux, in Tumbleweed.
Build goes fine, but launching fails. With a similar problem as mentioned above, and the 'renaming' the 3 wxSmith zip files.
Probably when starting a build by excluding these plug-in(s) things would have been ok too.

Code
sudo mv /usr/local/share/codeblocks/wxSmithAui.zip /usr/local/share/codeblocks/wxSmithAui.old
sudo mv /usr/local/share/codeblocks/wxsmithcontribitems.zip /usr/local/share/codeblocks/wxsmithcontribitems.old
sudo mv /usr/local/share/codeblocks/wxsmith.zip /usr/local/share/codeblocks/wxsmith.old

Conclusion: this problem is not solved yet, did anyone in the meantime had a look at it ?



for reference, I stumbled also upon: https://bbs.archlinux.org/viewtopic.php?id=308575

What wxWidget version is being used?
My wild guess is the png images; I checked one image file and if not wxCHECK_VERSION(3, 1, 6) then png images are used.
Edit: The single source file (wxsitemeditor.cpp) I checked was the only one that used the svg images if 3.1.6 or newer.

Tim S.
Pages: 1 2 3 4 5 [6] 7 8 9 10