Debugging a C program that uses pthreads is a complete nightmare,
BECAUSE -- or so googleing around suggests -- somehow libpthread is
by default "stripped".

Further googleing suggests that if I rebuild libpthread from source
without any "stripping" involved, then things will get better, debugging
wise.  That I am willing to try...

But WHERE can I download libpthread?  And HOW do I rebuild it so that the
"stripping" DOES NOT happen?  Moreover, HOW can I verify (without any
ifs, ands, or buts) that my new libpthread is absolutely and positively
NOT "stripped"?

---

Clarification of Question by ignorant-ga on 30 Jul 2004 10:58 PDT

The answer needs to be more than a glib remark like "recompile ...",
since there are potential problems.  For instance, following the outline
at http://hr.uoregon.edu/davidrl/glibc.html, I attempted to rebuild
the glibc library, but it would not compile (using gcc 3.4.1):
.
.
.
gcc sscanf.c -c -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes
-Wwrite-strings -g      -I../include -I.
-I/home/dpaddy/downloads/foo/stdio-common -I.. -I../libio 
-I/home/dpaddy/downloads/foo -I../sysdeps/i386/elf
-I../linuxthreads/sysdeps/unix/sysv/linux/i386
-I../linuxthreads/sysdeps/unix/sysv/linux
-I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread
-I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix
-I../linuxthreads/sysdeps/i386/i686 -I../linuxthreads/sysdeps/i386
-I../sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux
-I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman
-I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386
-I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../sysdeps/unix
-I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686
-I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386
-I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic 
-nostdinc -isystem /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.1/include
-isystem /tmp/headers -D_LIBC_REENTRANT -include
../include/libc-symbols.h       -D_IO_MTSAFE_IO -o
/home/dpaddy/downloads/foo/stdio-common/sscanf.o
sscanf.c:31: error: conflicting types for 'sscanf'
sscanf.c:31: error: conflicting types for 'sscanf'
sscanf.c:48: error: conflicting types for '_IO_sscanf'
../libio/iolibio.h:42: error: previous declaration of '_IO_sscanf' was here
sscanf.c:48: error: conflicting types for '_IO_sscanf'
../libio/iolibio.h:42: error: previous declaration of '_IO_sscanf' was here
sscanf.c: In function `sscanf':
sscanf.c:37: error: `va_start' used in function with fixed args
make[2]: *** [/home/dpaddy/downloads/foo/stdio-common/sscanf.o] Error 1
make[2]: Leaving directory `/home/dpaddy/downloads/glibc-2.3.2/stdio-common'
make[1]: *** [stdio-common/subdir_lib] Error 2
make[1]: Leaving directory `/home/dpaddy/downloads/glibc-2.3.2'
make: *** [all] Error 2

---

Request for Question Clarification by maniac-ga on 30 Jul 2004 18:00 PDT

Hello again,

Still no answer from Red Hat on your other problem.

For this question, I see two possible problems to answer:

 [1] How to efficiently debug a multiple task application?
and
 [2] How to build libpthread w/ all the symbols?

I can certainly answer the second question but based on my experience
with threaded applications am not sure how that will help with the
first.

Would you be willing to describe your application / problems with
debug? I may be able to suggest methods to debug more effectively and
avoid the need for the symbols in the pthread library.

If not, let me know and I'll walk you through the steps to rebuild the
source of the appropriate Red Hat glibc RPM. In the latter case,
indicate which version of Red Hat (or Fedora) you are using so I get
the right source to start with.

  --Maniac

PS: To verify the built library, I would use
  nm (object file or library)
to display the symbol names / debug data. It would either display the
symbols available or indicate no symbols are available.

PPS: Now that I think some more, another alternative is to add -g
-static to your compile / link operations to get additional debug data
w/o the need for the library rebuild. Let me know if that helps.

---

Clarification of Question by ignorant-ga on 03 Aug 2004 05:11 PDT

My main problem is broken tools, poorly designed tools, and lack of clear and
precise documentation...

In this case, since time was running out on me getting debugging done (I could
have been old fashoned and used print statements and trace files, but having a 
functional debugger seemed the better long term choice), I went ahead and paid
a Gentoo expert to wipe my system and recompile EVERYTHING from scratch making
positively sure that absolutely NOTHING was stripped.  That has cleared up my
pthread problems wrt ddd/gdb.  By the way, I have since read some buz in Gentoo
documentation confirming my suspicion that stripped libraries were the problem.

Your comments about "nm" and "-static" are appreciated, and you seem a pleasant
person.... so lets say you have "answered" my question; you are welcome to the
10 bucks.

Later. 
(...and happy hacking...)

---

Clarification of Question by ignorant-ga on 03 Aug 2004 05:18 PDT

One more thing: for the benefit of those perusing google answers (and if you
don't mind) please feel free to post a description of how to build libpthread.