我试图避免这个 Stackoverflow 条目中描述的情况： Debugging core files generated on a Customer's box。如果我静态编译所有库，我会避免在核心转储时始终收集共享库吗？我基本上想处于这样一种情况，我可以使用 gdb 加载核心文件并检查崩溃的应用程序。
如果我走静态链接我们需要的所有库的路线，我应该注意什么。我认为 glib 和 pthreads 可能会导致最大的问题。
Valgrind 会不再有用吗？如果我针对所有静态编译的二进制文件加载 Valgrind，它会发现错误吗？或者我们应该维护一个非静态编译的二进制文件，以便 Valgrind 继续工作。strace 怎么样？
我们经常崩溃，因为我们拥有庞大的安装基础，而且它也是一个遗留应用程序。收集所有共享库变得棘手 - 我需要另一个解决方案。
编辑：修正错字。
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.