DDD (gdb): No source: ../sysdeps/x86_64/elf/start.S: No such file bug; Missing XKeysymDB file bug

I came across a strange bug, or better said, strange behavior of ddd today. I have tried to debug my program and I have got this error dialogue:

DDD: No source
/home/v-teq/…/sysdeps/x86_64/elf/start.S: No such file or directory

Missing XKeysymDB file

I have tried to find out where was the problem:

v-teq@v-teq-laptop:~$ ddd --check-configuration
Checking for XKeysymDB... (none)
Warning: The `XKeysymDB' file is not in the default X file search path.
    If ddd was not compiled on this machine, ddd
    may not run properly (lots of warnings for unknown keysym names).
    and install it into your X project root (typically `/usr/lib/X11')
    or have the XKEYSYMDB environment variable point at it.

But as you can see, I found another error message that was ddd printing out – it couldn’t find XKeysymDB file. The solution was quite easy – only to find the XKeysymDB file in my /usr directory, because default /usr/lib/X11 path doesn’t exist anymore on my Debian based machine.

v-teq@v-teq-laptop:~$ find /usr -name XKeysymDB
/usr/share/X11/XKeysymDB

So the answer was /usr/share/X11/XKeysymDB in my case.

Now it’s easy to set environment variable and get ddd working again:

v-teq@v-teq-laptop:~$ XKEYSYMDB=/usr/share/X11/XKeysymDB ddd --check-configuration
Checking for XKeysymDB... /usr/share/X11/XKeysymDB

You can set variable pernamently of course (or you can echo this line into your ~/.bashrc or such file).
For sh, ksh or bash:

export XKEYSYMDB="/usr/share/X11/XKeysymDB"

For csh:

setenv XKEYSYMDB "/usr/share/X11/XKeysymDB"

DDD: No source: ../sysdeps/x86_64/elf/start.S

Now back to the first problem – error dialogue that said I didn’t compiled debugging information to my executables, so debuggers (ddd, gdb) weren’t able to use symbols from source files.

Take care if you have compiled your binary files (executables or libraries) really with debugging information (eg. -g option in gcc). My problem was, that my Makefile created executables from libraries with -g option, but libraries themselves were compiled without this option automatically (there was no rule to make *.o files in Makefile).

So my advice is to double check your Makefile, or command line if you’re compiling project manually, if you have really set the -g option. For example:

gcc -g -o main main.c

Or if you want to create *.o file before linking to final executable, don’t forget to check -g option in both cases:

gcc -g -c -o main.o main.c
gcc -g -o main main.o

You can also add something like that to your Makefile to compile *.o files with -g debugging option automatically:

CC=gcc
CFLAGS=-g
 
%.o: %.c
	$(CC) $(CFLAGS) -c $< -o $@

Subversion commands (svn)

SVN Update

svn update – Bring changes from the repository into your working copy.

$ svn update [-r <REV>] [<PATH>]

Usage examples:

$ svn update # update the whole working copy to the latest revision
$ svn update doc/ # update doc/ directory to the latest revision
$ svn update -r 128 # update (revert) the whole working copy to revision #128
$ svn update -r 56 stack.h stack.c # update (revert) stack.h and stack.c files to revision #56

SVN Merge

svn merge – Apply the differences between two sources to a working copy path.

$ svn merge -r <FROM_REV>:<TO_REV> [<PATH>]

Usage examples:

$ svn merge -r 58:56 stack.h # undo stack.h file changes from revision #58 to revision #56