Statically linking system libraries, libc, pthreads, to aid in debugging

Question

I am trying to avoid the situation described in this Stackoverflow entry: Debugging core files generated on a Customer's box. If I compile all the libraries statically will I avoid having to always gather the shared libraries when it core dumps? I essentially want to be in a situation where I can just load up the core file with gdb and examine the crashed application.

What should I watch out for if I go down the route of statically linking all the libraries we need. I figure glib and pthreads might cause the biggest problems.

Will Valgrind cease to be useful? If I load up Valgrind against the binary which has everything statically compiled will it find errors? Or shall we maintain a binary that isn't statically compiled so Valgrind continues to work. How about strace?

We crashes quite often as we have a large install base and it is also a legacy application. Gathering up all the shared libraries is becoming intractable - I need another solution.

Edit: fixed typo.

Alephnull

You will always need the core file; how else will you be able to examine the contents of memory at the time of the crash. – Petrarch

@Ignacio Vazquez-Abrams, thanks. I meant shared libraries. – Alephnull

Actually, you don't need the libraries themselves; the debugging symbols are enough (although not always available). – Petrarch

@IgnacioVazquez-Abrams If you had bothered to read the linked question, you'll see that your comment is false. – Regiment

@Employed: Which part of the linked question refutes what I've said? – Petrarch

@IgnacioVazquez-Abrams The answer explains why you do need the libraries from the target system to analyze the core. If by debugging symbols you meant "separate debuginfo files matching target system's libraries", then your comment is correct (but you didn't make that clear). OTOH, if you meant "debugging symbols for the application itself", then your comment is false. – Regiment

I figured that the "themselves" would disambiguate my wording. – Petrarch

Building on what @IgnacioVazquez-Abrams said, separate debug info files containing the debug symbols are documented in the GDB manual in "Section 18.2: Debugging Information in Separate Files". HTH! – Squamation

Answer 1

If I compile all the libraries statically will I avoid having to always gather the shared libraries when it core dumps

Yes.

However, contrary to popular belief, statically linked binaries are less portable than dynamically linked ones (at least on Linux).

In particular, if you use any of these functions: gethostbyname, gethostbyaddr, getpwent, getpwnam, getpwuid (and a whole lot more), you will get a warning at link time, similar to this:

Using 'getpwuid' in statically linked applications requires at runtime
the shared libraries from the glibc version used for linking.

What this warning means is that IF your customer has a different version of glibc installed from the one you used at link time (i.e. different from your system libc), THEN your program will likely crash. Since that is a clearly worse situation than your current one, I don't believe static linking is a good solution for you.

Regiment

Static linking is indeed not a good choice. Ulrich Drepper - one of the glibc maintainers and contributors - makes similar convincing arguments in "Static Linking Considered Harmful". – Squamation