Version: 3.0.0 (shipped with KDE 3.2.0) (using KDE KDE 3.2.0) Installed from: SuSE RPMs Debugging a C++ project with custom makefile requires to set a path to gdb in order to be able to debug the application. (Project->Project options->Debugger->Path to gdb) Entering /opt/customsw/gdb-5.3-local/bin/ Results in this gdb call /opt/customsw/gdb-5.3-local/bin/ gdb /home....and_so_on Note the extra space. Entering /opt/customsw/gdb-5.3-local/bin/gdb as path to gdb produces the expected result: /opt/customsw/gdb-5.3-local/bin/gdb gdb /home/...and_so_on This makes it impossible to debug the application. P.S.: From this behavior I see that "gdb" is added to the path. From the GUI i could not tell if "gdb" was to be included or not (and if not, if a trailing slash was required).
Seams a duplicate of bug 67487 But this one describes the problem much better.
I looked over the code and it seems to be the method GDBController::slotStart in gdbcontroller.cpp: ... emit gdbStdout(QString( config_gdbPath_ + " gdb " + application + " -fullname -nx -quiet" ).latin1()); ...
That's just an (incorrect) informative message that goes to the gdb window. As you can see from the line above the line you quoted, the dbgProcess should be started correctly. *dbgProcess_ << config_gdbPath_ + "gdb" << application << "-fullname" << "-nx" << "-quiet"; emit gdbStdout(QString( config_gdbPath_ + " gdb " + application + " -fullname -nx -quiet" ).latin1()); Note also that if gdb is in your path you don't need to set the path to gdb. I agreed it's hard to tell what you should enter for the gdb path and with the misleading output it make things even more murky. I'm not sure what the real error is here beyond "debugging doesn't work". What error message are you actually seeing?
I tried to reproduce the error but was unsuccessful with this. Since I further developed the project without kdevelop it is quite likely that my problem was a different one and the gdb window message lead me on the wrong track. The rest of my environment (gdb version etc.) did change a bit since that day, too. If you repair the message this report could be closed from my point of view. If I remember correctly it is possible for me to reopen it if it is required? Just by the way: The description string in the GUI could be changed to read "directory where gdb resides" or something like that.
Done Directory where gdb resides (eg /usr/bin/) and closing as worksforme ...