静态链接系统库、libc、pthreads，以帮助调试

Question

我正在努力避免出现此 Stackoverflow 条目中描述的情况：Debugging core files generated on a Customer's box。如果我静态编译所有库，我会避免在核心转储时始终收集共享库吗？我基本上想处于一种可以使用 gdb 加载核心文件并检查崩溃的应用程序的情况。

如果我走静态链接我们需要的所有库的路线，我应该注意什么。我认为 glib 和 pthreads 可能会导致最大的问题。

Valgrind 会不再有用吗？如果我针对所有静态编译的二进制文件加载 Valgrind，它会发现错误吗？或者我们应该维护一个非静态编译的二进制文件，以便 Valgrind 继续工作。 strace 呢？

我们经常崩溃，因为我们拥有庞大的安装基础，而且它也是一个遗留应用程序。收集所有共享库变得难以处理 - 我需要另一个解决方案。

编辑：修正错字。

Answer 1

如果我静态编译所有库，我将避免在核心转储时始终收集共享库

是的。

然而，与流行的看法相反，静态链接的二进制文件比动态链接的二进制文件更不便携（至少在 Linux 上）。

特别是，如果您使用以下任何功能：gethostbyname、gethostbyaddr、getpwent、getpwnam、getpwuid（以及更多），您将在链接时收到警告，类似这样：

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

此警告的意思是 IF 您的客户安装的 glibc 版本与您在链接时使用的版本不同（即不同于 您的 系统 libc）， 那么您的程序可能会崩溃。由于这显然比您当前的情况更糟，因此我认为静态链接对您来说不是一个好的解决方案。