Forgot to mention: I pulled HEAD from CVS today (26/05/03), but still same problem.... 

I also am having the same problem with Alpha 4. However, when I downloaded CVS 
Head 5-25-03, I created a simple helo world project with the appwizard.  I added 
some lines of code to it and set a break point at the cout statement.  The 
debugger did start and it stoped execution at the breakpoint at the cout 
statement.  I tried to run to the next line and the debugger didn't stop until in 
reached the closing brace of the program.  Below is the code I used and below the 
code is the debugger output from the GDB window. 
 
-Gregory 
 
#include <iostream> 
#include <cstdlib> 
 
using namespace std; 
 
int main(int argc, char *argv[]) 
{ 
  cout << "Hello, world!" << endl; 
  int a; 
  a = 5; 
  a++; 
  a = a*8; 
  return EXIT_SUCCESS; 
} 
 
 
Debugger Output: 
 
#include <iostream> 
#include <cstdlib> 
 
using namespace std; 
 
int main(int argc, char *argv[]) 
{ 
  cout << "Hello, world!" << endl; 
  int a; 
  a = 5; 
  a++; 
  a = a*8; 
  return EXIT_SUCCESS; 
} 

Opps, sorry.  Here is the debugger output. 
 
-Gregory 
 
gdb /home/gcolds/projects/hi/src/hi -fullname -nx -quiet 
(gdb) set edit off  
(gdb) set confirm off  
(gdb)  
(gdb)  
(gdb) set print static-members off  
(gdb) tty /dev/pts/1  
(gdb) set width 0  
(gdb) set height 0  
(gdb) set stop-on 1  
(gdb) handle SIG32 pass nostop noprint  
(gdb) handle SIG43 pass nostop noprint  
(gdb) set print asm-demangle on  
(gdb) cd /home/gcolds/projects/hi/src  
(gdb) break hi.cpp:12  
Breakpoint 1 at 0x8048639: file hi.cpp, line 12. 
(gdb) run  
Stopped due to shared library event 
(gdb) continue  
Stopped due to shared library event 
(gdb) continue  
Stopped due to shared library event 
(gdb) continue  
 
Breakpoint 1, main (argc=1, argv=0xbffff6c4) at hi.cpp:12 
/home/gcolds/projects/hi/src/hi.cpp:12:146:beg:0x8048639 
(gdb) backtrace  
#0  main (argc=1, argv=0xbffff6c4) at hi.cpp:12 
#1  0x401218ae in __libc_start_main () from /lib/libc.so.6 
(gdb) info breakpoints  
Num Type           Disp Enb Address    What 
1   breakpoint     keep y   0x08048639 in main at hi.cpp:12 
	breakpoint already hit 1 time 
(gdb) next  
/home/gcolds/projects/hi/src/hi.cpp:18:240:beg:0x8048658 
(gdb) backtrace  
#0  main (argc=1, argv=0xbffff6c4) at hi.cpp:18 
#1  0x401218ae in __libc_start_main () from /lib/libc.so.6 
 

Jeroen, 
So if you typed the very first line "/bin/sh -c ..." what happens? What happens 
if you cd into /mnt/share/iebserver and then did it. And from .../src? 
Try dropping libtool and in the src dir do "gdb iebserver". Anything 
interesting? 
 
Note the "Excess command line arguments ignored -nx". Very interesting. What 
does the info pages say for gdb startup? 
 
 
Gregory, 
I suspect you have compiled with optimisation. All the code with variable a is 
likely to be removed. Make sure that -O2 is not used in the compile line and -g 
is (preferrably -g3) 
 
jbb 
 
 

Subject: Re:  debugger will not start

John,

It's strange, because libtool doesn't even do anything from the command
line. See below. What added value does it have (when working that is)
over directly invoking gdb?

Here's the output of the various commands:

> ------- Additional Comments From jbb@kdevelop.org  2003-05-27 01:06
> ------- Jeroen,
> So if you typed the very first line "/bin/sh -c ..." what happens?

[dizzl@newton dizzl]$ /bin/sh -c /mnt/share/iebserver/libtool gdb /mnt/share/iebserver/src/iebserver -fullname -nx -quiet
libtool: warning: cannot infer operation mode without MODE-ARGS
libtool: you must specify a MODE
Try `libtool --help' for more information.

> What happens if you cd into /mnt/share/iebserver and then did it.

[dizzl@newton dizzl]$ cd /mnt/share/iebserver
[dizzl@newton iebserver]$ /bin/sh -c /mnt/share/iebserver/libtool gdb /mnt/share/iebserver/src/iebserver -fullname -nx -quiet
libtool: warning: cannot infer operation mode without MODE-ARGS
libtool: you must specify a MODE
Try `libtool --help' for more information.

> And from .../src?

[dizzl@newton iebserver]$ cd src
[dizzl@newton src]$ /bin/sh -c /mnt/share/iebserver/libtool gdb /mnt/share/iebserver/src/iebserver -fullname -nx -quiet
libtool: warning: cannot infer operation mode without MODE-ARGS
libtool: you must specify a MODE
Try `libtool --help' for more information.

> Try dropping libtool and in the src dir do "gdb iebserver". Anything
> interesting?

[dizzl@newton src]$ gdb /mnt/share/iebserver/src/iebserver -fullname -nx -quiet
(gdb)

> Note the "Excess command line arguments ignored -nx". Very
> interesting. What does the info pages say for gdb startup?

This is from the man-page:
       -nx
       -n     Do not  execute  commands  from  any  ‘.gdbinit’  initialization
              files.  Normally, the commands in these files are executed after
              all the command options and arguments have been processed.

Seems like -n and -nx are the same...

Regards,
  Jeroen            mailto:dizzl@xs4all.nl          http://www.dizzl.com

The problem arises because of the following entry in the 
"project_name.kdevelop" file (gideon alpha4): 
========== 
  <kdevdebugger> 
    <general> 
      <programargs></programargs> 
      <gdbpath></gdbpath> 
      <dbgshell>libtool</dbgshell> 
      <breakonloadinglibs>true</breakonloadinglibs> 
      <separatetty>false</separatetty> 
      <floatingtoolbar>false</floatingtoolbar> 
    </general> 
    <display> 
      <staticmembers>false</staticmembers> 
      <demanglenames>true</demanglenames> 
    </display> 
  </kdevdebugger> 
=========== 
 
As you can see, the above entry is the default value for debugging option. 
It is simply generated by opening "project option", go to "debug" section, 
and click "ok". 
 
Removing the above entry will cause debugger to start again. Note that 
when the entry present, kdevelop launches 
"/bin/sh -c projectpath/libtool gdb projectpath/src/program_name", 
which will cause the failure, whereas when the entry is not presented, 
kdevelop simply lauches "gdb projectpath/src/program_name -quiet ...". 
 
 
Regards, 
Verdi 

John, you were right.  I thought setting that option in the new automake 
manager would do it but I had to set it in the project configuration.  So 
it seems that removing libtool was enough to solve that problem.   
 
Thanks 
 
-Greg 

In a nutshell, libtool wraps the executable and organises the environement so 
that any shared libs you are working on are found from _within_ your project 
rather than any old installed shared libs. 
 
So it could be important that you use libtool depending on whether you have a 
shared lib in your project. 
 
However, note that kparts are shared libs but these are "dlopened" and 
unfortunately your project part won't be found if it's not installed. This 
needs some work to fix, but the workaround is to intall it so it's low(ish) on 
the priority :( 
 
What I'd really like to know is why your libtool is failing. 
 
Do a "which libttol". There should be one in /usr/bin? In the debugger optioins 
try setting libtool to be "/usr/bin/libtool" and see if that works. 
 
jbb 
 
 

Hello again John.  I followed your instructions regarding libtool and it  
worked.  When I put /usr/bin/libtool in the debugger shell option,  
debugging worked.  I then changed it back to just libtool and I recieved  
the "no file or directory error".  I did this a couple of times and recieved the same 
results.  I guess that means that the libtool in the project directory isn't being found or 
is faulty. 
 
-Greg 

Hi Gregory, 
 
A problem here could be that the admin directory in the new project is not from 
the kde version you have. 
 
Can you get the admin directory for kde3.1 - your need to get this from the kde 
web site (it's in package kde-common) and replace the admin directory in your 
project with this one (remember to back up your old one first:). Recompile and 
try debugging again 
 

Hi, 
 
The exact same thing happens here (running CVS of 05/08/2003 on SuSE 8.2). 
 
I have noticed that /usr/bin/libtool claims to be version 1.4.3 whereas libtool 
in my project directory said it was 1.4.1. 
 
Simply updating libtool in the project directory by copying /usr/bin/libtool 
makes the debugger start, so I suppose this is the only file that affects this. 
 
I then did "make clean" and "make distclean" to make libtool disappear and ran 
"./configure" again to have a new one generated. 1.4.1 popped up again and the 
problem reappears: 
 
./libtool --version 
ltmain.sh (GNU libtool) 1.4.1 (1.922.2.34 2001/09/03 01:22:13) 
 
This is interesting as I have 1.4.3 installed: 
 
> rpm -qa | grep libtool 
libtool-1.4.3-43 
> /usr/bin/libtool --version 
ltmain.sh (GNU libtool) 1.4.3 (1.922.2.111 2002/10/23 02:54:36) 
 
I am no auto-tools expert, but it seems that the problem is: 
 
- KDevelop 3 requires libtool 1.4.3 
- I have libtool 1.4.3 installed: 
- A KDevelop project's libtool is generated by ./configure 
- Autoconf generates a ./configure which generates libtool 1.4.1 
 
So, the issue here is to have autoconf generate a ./configure which generates a 
1.4.3 libtool. 
 
Cheers! 
 

Subject: Re:  debugger will not start

Thanks for the response! Strangely my problem was solved already by 
editing the project's xml file, given the hints of another replyer. 
Hopefully your description will be of use to others, as this problem 
seemed to be heavily encountered, but not documented...

Regards,
Jeroen

On Wednesday 06 August 2003 11:23, you wrote:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
> http://bugs.kde.org/show_bug.cgi?id=58999
>
>
>
>
> ------- Additional Comments From karypid@inf.uth.gr  2003-08-06 11:23
> ------- Hi,
>
> The exact same thing happens here (running CVS of 05/08/2003 on SuSE
> 8.2).
>
> I have noticed that /usr/bin/libtool claims to be version 1.4.3
> whereas libtool in my project directory said it was 1.4.1.
>
> Simply updating libtool in the project directory by copying
> /usr/bin/libtool makes the debugger start, so I suppose this is the
> only file that affects this.
>
> I then did "make clean" and "make distclean" to make libtool
> disappear and ran "./configure" again to have a new one generated.
> 1.4.1 popped up again and the problem reappears:
>
> ./libtool --version
> ltmain.sh (GNU libtool) 1.4.1 (1.922.2.34 2001/09/03 01:22:13)
>
> This is interesting as I have 1.4.3 installed:
> > rpm -qa | grep libtool
>
> libtool-1.4.3-43
>
> > /usr/bin/libtool --version
>
> ltmain.sh (GNU libtool) 1.4.3 (1.922.2.111 2002/10/23 02:54:36)
>
> I am no auto-tools expert, but it seems that the problem is:
>
> - KDevelop 3 requires libtool 1.4.3
> - I have libtool 1.4.3 installed:
> - A KDevelop project's libtool is generated by ./configure
> - Autoconf generates a ./configure which generates libtool 1.4.1
>
> So, the issue here is to have autoconf generate a ./configure which
> generates a 1.4.3 libtool.
>
> Cheers!

Regards,
  Jeroen                         mailto:jdizzl@xs4all.nl

I also had problem to start the debugger for my project.  
 
For me it seems to be a libtool problem. I use the libtool version 1.4.3 (1.922.2.110 
2002/10/23 01:39:54). When I tried to start the debugger I got the following error 
message (with --debug for libtool added): 
 
+ eval exec '"$cmd"$args' 
++ exec gdb '"/home/kdecvs/emu2509/debug/src/.libs/lt-emu2509"' '"--fullname"' '"--
nx"' 
Excess command line arguments ignored. ("--nx") 
"/home/kdecvs/emu2509/debug/src/.libs/lt-emu2509": File or directory not found. 
/home/kdecvs/emu2509/"--fullname": File or directory not found. 
 
 
So I changed the following lines in the /home/kdecvs/emu2509/debug/libtool script: 
 
# Quote arguments (to preserve shell metacharacters). 
file=`$echo "X$file" | $Xsed -e "$sed_quote_subst"` 
args="$args \"$file\"" 
 
to 
 
# Quote arguments (to preserve shell metacharacters). 
file=`$echo "X$file" | $Xsed -e "$sed_quote_subst"` 
args="$args $file" 
 
and it works now. 
 
I hope it helps... 
 
Christian Loose 

I have seen this before and the reason is quoting problem: 
Note the: '"--fullname"'  (single quote) (double qoute)...(double)(single) 
 
Text withing double quotes get variable substituted. 
But text within single quotes does not - the above counts as single quoted. 
The single quotes gets removed and the resulting _option_ is "--fullname" 
(that sounds correct doesn't it?) 
Problem is that the double quotes are concidered a part of the argument! 
But there are no options starting with a double quote... 

*** Bug 75186 has been marked as a duplicate of this bug. ***

This was solved in HEAD and in KDE_3_2_BRANCH

*** Bug 58600 has been marked as a duplicate of this bug. ***