Code::Blocks Forums
User forums => Help => Topic started by: realruntime on August 27, 2005, 10:24:36 pm
-
Hello,
I tried to debug using CodeBlocks but I didn't know how and I didn't find any resource to debug with gdb.
Thanks,
Mustafa ELBanna
-
Um... currently it's a bit complicated. See, the debug button just runs the program unless you have set breakpoints before.
This is fixed in CVS, where you can just advance one line and start debugging from there.
Anyway, to debug your program in codeblocks, make sure you compile with the "produce debugging symbols" option, and you can use the "run to this line" button to start debugging.
Good luck! :)
-
Hello,
Thanks, But I did this before I post and it didn't work. after choosing produce debugging symbols option. then try to make a break poing and debug using gdb, this message appears The project/Target has no debugging info. Please change this in the project's build options and retry...
Waiting for help.
Thanks,
Mustafa ELBanna
-
Hello,
Thanks, But I did this before I post and it didn't work. after choosing produce debugging symbols option. then try to make a break poing and debug using gdb, this message appears The project/Target has no debugging info. Please change this in the project's build options and retry...
Waiting for help.
Did you recompile (ie Compile -> Rebuild or just Ctrl-F11) after setting that option? Just setting it doesn't magically add debugging symbols to already compiled binaries, I'm afraid ;).
Maybe that message should be clearer about what "retry" in this case is, as it isn't just trying to debug again.
-
Hello,
I sure rebuild the app. after changing the option but it doesn't really works and the message appears again. and the GDB debugger generate this message:
"No symbol table is loaded. Use the "file" command.
error"
Thanks,
Mustafa ELBanna
-
Wait, what compiler are you using? Compilers other than MinGW/GCC (depending on whether you're using Windows or Linux/Unix) may not be supported by the GDB debugger...
For other compilers you may have to use an external debugger or wait until Code::Blocks supports more debuggers :(.
Well, that or switch compilers, ofcourse :mrgreen:.
-
Hello,
Thanks, I really Microsoft C++ 2003 compiler so it appears that it's not compatible with gdb. can you tell me what debugger can I use now with MS compiler?!
Thanks,
Mustafa ELBanna
-
download the platform sdk.
make sure produce debugging symbols is checked
add /debug to extra link options :\
rebuild
psdk->install debugging tools for windows
debug with windbg
this gives you source level debugging.
windbg tutorial here: http://www.codeproject.com/debug/windbg_part1.asp
-
Hello,
Command window of WinDbg opens and this message generates for me
"Could not create process 'w -annotate=2 -silent', Win32 error 2
The system cannot find the file specified"
!!??
Thanks,
Mustafa ELBanna
-
Hello,
Thanks, I really Microsoft C++ 2003 compiler so it appears that it's not compatible with gdb.
:roll: Why, oh why, didn't we add a "Debugging is only supported for GCC and compatibles" message?
-
Hello,
I'm sorry but when I use GCC with DirectX it generate linking error and when I use the same options with MS C++ it builds successfully. So I use MS.
Thanks,
Mustafa ELBanna
-
That's because it uses the precompiled libs shipping with your version of the compiler. You should expect that using an MS API would rely on the MS tools...
-
A little off-topic, but this might help...
http://mywebpage.netscape.com/PtrPck/progtopics.htm
http://www.spacejack.org/games/mingw/mingw-dx.html
Tells how to link DirectX with GCC programs...
(All hail Google! :P )
-
So it looks like mingw can just use standard .lib files as well (in addition to the included .a files). Didn't look like it was too difficult to get mingw gcc & directx working.
-
Hello,
really don't understand you, besides that is the a files related to linux??
Thanks,
Mustafa ELBanna
-
actually i didn't understand either. I thought the library formats depended on the compiler, not the extension. So if it's GCC, the .a / .lib file will have the same format, no matter the operating system... i suppose....
-
Yeap that's right, I'll quote from the link you provided:
simply change the names of the MS libraries to lib*.a (e.g. rename ddraw.lib to libddraw.a, and then don't forget to add the library search path with the -L option.)
Having the lib*.a format just makes gcc "understand" -l[name of lib] inputs. Though I don't know who you were refering to by saying you don't understand, I was just saying that if you include the dx libs using ms compiler the libraries will be straight available to u and with minGW you' ll have to provide path etc.
-
Oh, true. I guess if you can build a cross-compiler under linux to generate windows binaries, the linker can easily be configured to just output windows libs (and then use the lib*.a convention for "portability").
-
Can't answer that for sure but I think no. The .a libs u use under windows have been built under windows.
-
yeah but the naming convention is the same so -llibname works on both. that's all I mean by "portability".