71
Development / Re: special handling of the macro replacement ""?
« Last post by AndrewCot on January 30, 2026, 10:41:01 am »Have a look at https://sourceforge.net/p/codeblocks/tickets/1188/ .....
News:
Accounts with zero posts and zero activity during the last months will be deleted periodically to fight SPAM!
Recent Posts
72
General (but related to Code::Blocks) / Re: Code::Blocks 25.03: Debugger fails to catch breakpoints in inline/template-enhan
« Last post by ollydbg on January 30, 2026, 04:21:11 am »I think your issue is not Code::Blocks related.
Because Code::Blocks just send commands by driving the gcc to compile, and drving the gdb to debug, so you can looked at the compiler plugin full log and debugger plugin full log to know all the communications.
Because Code::Blocks just send commands by driving the gcc to compile, and drving the gdb to debug, so you can looked at the compiler plugin full log and debugger plugin full log to know all the communications.
73
General (but related to Code::Blocks) / Code::Blocks 25.03: Debugger fails to catch breakpoints in inline/template-enhan
« Last post by promotebrilliant on January 30, 2026, 03:53:05 am »I'm using Code::Blocks 25.03 with GCC 12/13 and a project configured by CMake to build with multiple template/inline modules. After a successful build, when I run the debugger:
Breakpoints in inline/template functions (especially when called from template specialization) sometimes only jump once or don't catch at all, even with the debug symbol.
While breakpoints in other normal code (non-template/inline) work perfectly fine.
I've enabled -g3 and no optimization (
), and CMake verifies that debug info is included in the binary.
Has anyone else encountered a similar problem in Code::Blocks?
Is this a bug related to how CB's GDB/Debugger handles template/inline symbols?
Are there any settings in Settings → Debugger or Project that I'm missing?
Thanks everyone!
Breakpoints in inline/template functions (especially when called from template specialization) sometimes only jump once or don't catch at all, even with the debug symbol.
While breakpoints in other normal code (non-template/inline) work perfectly fine.
I've enabled -g3 and no optimization (
), and CMake verifies that debug info is included in the binary.Has anyone else encountered a similar problem in Code::Blocks?
Is this a bug related to how CB's GDB/Debugger handles template/inline symbols?
Are there any settings in Settings → Debugger or Project that I'm missing?
Thanks everyone!
74
Development / Re: special handling of the macro replacement ""?
« Last post by ollydbg on January 29, 2026, 04:53:05 am »Oh, I change the mind, it looks like this patch should solve the issue, see here:
* sdk: try to handle empty valued members in global compiler variable
* sdk: try to handle empty valued members in global compiler variable
75
Development / Re: special handling of the macro replacement ""?
« Last post by ollydbg on January 29, 2026, 04:10:26 am »I did some test, and if the empty value key is allowed to add in the global compiler variable, the result may be that there are a lot of predefined keys saved to the config file, for example, see below:
You can see, I don't want to do that DDD is a user defined key, and its value is empty. While the CFLAGS is predefined key, and its value is also empty.
So, I think the solution is: using the predefined value string, for example, a value named: __EMPTY__ or just an empty string "", then in the code when we get the value, we have to check the result, and remove the __EMPTY__ or "" in the command line.
Code
<sets>
<default>
<cccccc>
<DDD>
<str>
<![CDATA[]]>
</str>
</DDD>
<BBB>
<str>
<![CDATA[xxx]]>
</str>
</BBB>
<CFLAGS>
<str>
<![CDATA[]]>
</str>
</CFLAGS>
<BIN>
<str>
<![CDATA[]]>
</str>
</BIN>
<LFLAGS>
<str>
<![CDATA[]]>
</str>
</LFLAGS>
<OBJ>
<str>
<![CDATA[]]>
</str>
</OBJ>
<LIB>
<str>
<![CDATA[]]>
</str>
</LIB>
<INCLUDE>
<str>
<![CDATA[]]>
</str>
</INCLUDE>
<BASE>
<str>
<![CDATA[aaaa]]>
</str>
</BASE>
</cccccc>
You can see, I don't want to do that DDD is a user defined key, and its value is empty. While the CFLAGS is predefined key, and its value is also empty.
So, I think the solution is: using the predefined value string, for example, a value named: __EMPTY__ or just an empty string "", then in the code when we get the value, we have to check the result, and remove the __EMPTY__ or "" in the command line.
76
General (but related to Code::Blocks) / Re: Welcome Newcomers - PLEASE READ!!!
« Last post by rjmolloy on January 28, 2026, 08:27:21 pm »I'm here and I'm real and really like C::B.
77
Development / Re: special handling of the macro replacement ""?
« Last post by gd_on on January 28, 2026, 05:54:21 pm »To add some informations:
In standard cbp files, there is an environment variable defined as:
When it is used in standard cbp files, as:
there are no problems.
In my unified workspace/cbp files, I define a wxwidgets path as, in my case, C:\wxWidgets-3.3.1 as the base, and in a user-defined field, I have created a wx_cfg variable. If I set this variable with nothing (an empty field), the variable is eliminated after a click on the save button. It's why, as in standard cbp files, I tried to set an empty string by "". Apparently, this is the problem described by ollydbg when I use a variable as:
In standard cbp files, there is an environment variable defined as:
Code
<Variable name="WX_CFG" value="" />Code
<Add directory="$(#wx33_64.lib)/gcc_dll$(WX_CFG)In my unified workspace/cbp files, I define a wxwidgets path as, in my case, C:\wxWidgets-3.3.1 as the base, and in a user-defined field, I have created a wx_cfg variable. If I set this variable with nothing (an empty field), the variable is eliminated after a click on the save button. It's why, as in standard cbp files, I tried to set an empty string by "". Apparently, this is the problem described by ollydbg when I use a variable as:
Code
<Add directory="$(#WXWIDGETS)/lib/gcc_dll$(#WXWIDGETS.WX_CFG)78
Using Code::Blocks / Re: crash when I try to open a wxsmith file under C::B against wx 3.3.1
« Last post by ollydbg on January 28, 2026, 02:40:13 pm »I first found a workaround patch, see here:
* wxSmith: workaround an assert issue happens when showing asmwarrior/codeblocks_sfmirror@e627289
Tested and it won't crash/assert now.
But this is only a workaround, should find a better way.
* wxSmith: workaround an assert issue happens when showing asmwarrior/codeblocks_sfmirror@e627289
Tested and it won't crash/assert now.
But this is only a workaround, should find a better way.
79
Development / Re: special handling of the macro replacement ""?
« Last post by ollydbg on January 28, 2026, 09:33:30 am »Make sure you get approval by MortenMacFlybefore making any changes. Check out the SF tickets for posts on macro and hopefully you will fins the ticket and have a read before you spend time on this as you may end up wasting your time.
BTW I agree with you.
Hi, AndrewCot, long time no see.
I think it is a good direction.
Maybe there are similar topics in the sourceforge tickets.
So I will search for that.
To switch between the debug version of wx library, using the unified workspace or cbp project is much easier. We don't need to replace or editor each cbp files.
80
Development / Re: special handling of the macro replacement ""?
« Last post by AndrewCot on January 28, 2026, 09:21:14 am »Make sure you get approval by MortenMacFlybefore making any changes. Check out the SF tickets for posts on macro and hopefully you will fins the ticket and have a read before you spend time on this as you may end up wasting your time.
BTW I agree with you.
BTW I agree with you.