Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo.
If you want to use apt (or dselect, synaptic or whatever) you need to add the following entries to /etc/apt/sources.list :
deb http://apt.jenslody.de/ any dbg
deb-src http://apt.jenslody.de/ any dbg
and remove entries for the normal nightlies.
Alternatively you can download the deb's directly from http://apt.jenslody.de/pool/dbg/c/codeblocks/ (http://apt.jenslody.de/pool/dbg/c/codeblocks/) .
Revision is 7549, 7550 is unrelated to debugger-branch.
Maybe a bug:
Set BP in plugins\codecompletion\codecompletion.cpp line 509, and add watch variable "repl", and when c::b hits BP, it shows "Parsing GDB output failed for 'repl'!"
debugger log below:
> whatis repl
type = StringToStringMap
>>>>>>cb_gdb:
> output repl
std::map with 20 elements = {["BEGIN_EVENT_TABLE"] = "-END_EVENT_TABLE", ["WXDLLEXPORT"] = "", ["WXEXPORT"] = "", ["WXIMPORT"] = "", ["_GLIBCXX_BEGIN_NAMESPACE"] = "+namespace std {", ["_GLIBCXX_BEGIN_NAMESPACE_TR1"] = "namespace tr1 {", ["_GLIBCXX_BEGIN_NAMESPACE_VERSION"] = "", ["_GLIBCXX_BEGIN_NESTED_NAMESPACE"] = "+namespace std {", ["_GLIBCXX_END_NAMESPACE"] = "}", ["_GLIBCXX_END_NAMESPACE_TR1"] = "}", ["_GLIBCXX_END_NAMESPACE_VERSION"] = "", ["_GLIBCXX_END_NESTED_NAMESPACE"] = "}", ["_GLIBCXX_STD"] = "std", ["_GLIBCXX_STD_D"] = "std", ["_GLIBCXX_STD_P"] = "std", ["_GLIBCXX_VISIBILITY"] = "+", ["_STDEXT_BEGIN"] = "namespace std {", ["_STDEXT_END"] = "}", ["_STD_BEGIN"] = "namespace std {", ["_STD_END"] = "}"}>>>>>>cb_gdb:
I'm using gdb with python.
@OBF
I found a tiny bug. If I have such code:
int main()
{
int size;
size = 1;
return 0;
}
When debugging, if my mouse is hover the "size", and I press the CTRL, there is no value shown.
I guess this is because that "size" is a keyword of C++, right?
If I run command "p size" in the debugger gdb text control, it works.
Can we solve this?
Hello,
first of all, I am relatively new to C::B, but I think it is a good and very intuitive and easy-to-use IDE. Thanks so far.
But there are some things I encountered (sorry, if they are a re-post, even more, if I oviously did something wrong ::)):
(1) Looking for the "Set Next Statement" feature I came across this build, but it seems this is not working with XP SP3 and GNU gdb 6.5.50.20060706-cvs (cygwin-special) -- a quite old gdb, I know.... Whenever I try to Set Next Statement the debugger seems to hang, I neither gets there, nor is it possible to stop the debuggee.
(2) Another issue I found is that the watch list's columns do not always remain their size after I stop debugging. So I always have to resize them each time I restart debugging, which is also not that easy, because dragging will be interrupted, if a tooltip appears inbetween.
(3) When setting breakpoints in lexer/parser files, the program is being stopped correctly, and the debugger output window shows the file/line number as expected, but the arrow is missing...
(4) Which seems to be more serious: When trying to set a breakpoint in a file, which exists with the same name in different folders, the debuggee will not be halted, probably due to the wrong file having been picked. The configuration under which it happend to me is as follows:
Project 'sm' is using a custom makefile, which compiles all C files from 'sm' and 'tl' into 'sm/obj' and links to 'sm/bin'. I have a backup copy of 'tl' in 'sm' and this seems to cause the trouble! Although stated as "..\tl\tl.c" in the cbp file, the breakpoint is not set there, and stepping into a tl-function from 'sm/commgr.c' resulted in 'sm/tl/tl.c' being opened. Until I removed 'sm/tl/' from disk. It now works, but it took me some time to find out....
Directory structure:
prj/
|
+-- sm/
| +-- bin/
| | \-- sm*
| |
| +-- obj/
| | |
| | +-- commgr.o
| | +-- main.o
| | +-- sm.o
| | \-- tl.o
| |
| +-- Makefile
| +-- commgr.c
| +-- main.c
| +-- sm.c
| +-- sm.cbp
| +-- sm.workspace
| |
| \-- tl
| |
| +-- tl.c (stepped into)
| \-- tl.h
|
\-- tl/
|
+-- tl.c (breakpoint set)
\-- tl.h
Would be nice, if this could be fixed, and released in a new nightly very soon... really looking forward to it. ;D
Cheers,
Tobias