Hi,
Some months ago I posted this problem with an own makefile and breakpoints:
http://forums.next.codeblocks.org/index.php?topic=4064
One nice day I downloaded the nightly build CB_20061109_rev3197. There the source files were given relative when C::B sets a breakpoint. So it actually solved my problem. Now I downloaded a new nightly build and the problem is there again. Under the advanced compiler options I found now an option "Use Full Paths for source files (GDB workaround)". But this options doesn't change this behavior. Is there anything I could do or should I stick to the old version?
Thank you,
Kai
Quote from: kai7 on January 31, 2007, 12:10:37 PM
Hi,
Some months ago I posted this problem with an own makefile and breakpoints:
http://forums.next.codeblocks.org/index.php?topic=4064
One nice day I downloaded the nightly build CB_20061109_rev3197. There the source files were given relative when C::B sets a breakpoint. So it actually solved my problem. Now I downloaded a new nightly build and the problem is there again. Under the advanced compiler options I found now an option "Use Full Paths for source files (GDB workaround)". But this options doesn't change this behavior. Is there anything I could do or should I stick to the old version?
Thank you,
Kai
Others have found that removing spaces and special chars from filenames solves these problems.
QuoteOthers have found that removing spaces and special chars from filenames solves these problems.
Thank you for this tip. I tried it (removed the '+' from the path) but it didn't change. I think the problem is that in my makefile only relative paths are used. And it seems that GDB can't convert them to absolute paths.
Is there an update regarding this issue because I'm experiencing the same thing. As soon as I try to use my own Makefile I can longer debug and breakpoints don't get hit. The actual error message I get is:
Debugger name and version: GNU gdb 5.2.1
No source file named C:/source/qt2/main.cpp.
I'm using Qt, so if I don't use the custom makefile, I can debug, but then my resource files don't get included properly. Kind of a catch-22.
Never mind...I can see that this was a gdb issue and not a CB issue. Upgraded to the most recent version of gdb and now everything works like a charm.
Good for you. :-) Unfortunately I am already using the most recent version (6.3.2). One thing I found out is quite interesting: An "info source" gives this:
(gdb) info source
Current source file is ../../src/MainWin.cpp
Compilation directory is d:/Daten/C++/FrontDesign/FrontDesign.wx/src/
Located in d:/Daten/C++/FrontDesign/FrontDesign.wx/src/../../src/MainWin.cpp
And so a
break d:/Daten/C++/FrontDesign/FrontDesign.wx/src/../../src/MainWin.cpp:xxx
is working as well. So it seems to be a relative-absolute path converting problem within the gdb. So I wouldn't blame CB for this problem. But I am hoping to work around it with CB. ;-)
QuoteSo it seems to be a relative-absolute path converting problem within the gdb. So I wouldn't blame CB for this problem. But I am hoping to work around it with CB.
It's already worked out for you. Just rebuild your project (and any libraries linked to it and
you compiled them yourself) and the problem will be gone. This is the reason why absolute filenames are used now when compiling: so gdb can find the files.
QuoteIt's already worked out for you. Just rebuild your project (and any libraries linked to it and you compiled them yourself) and the problem will be gone. This is the reason why absolute filenames are used now when compiling: so gdb can find the files.
Yes, if I would compile it with C::B. But I use my own makefile which is created with an automake script. There the relative paths are still used. Until now I didn't find a way to use absolute paths with such a makefile...
Why not doing the obvious. :oops: I just ran the configure script using the absolute path of it. No I have a makefile with absolute paths in it and all my problems are solved. Sorry for the "ado about nothing".