静态链接系统库,libc,pthreads,以帮助调试 [英] Statically linking system libraries, libc, pthreads, to aid in debugging

查看:190
本文介绍了静态链接系统库,libc,pthreads,以帮助调试的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我试图避免在这个Stackoverflow条目中描述的情况:调试客户框中生成的核心文件。如果我静态编译所有库,我将避免在核心转储时总是收集共享库吗?我基本上希望处于一种情况,我可以用gdb加载核心文件并检查崩溃的应用程序。



如果我失败了,应该注意什么静态链接我们需要的所有库的路线。我认为glib和pthreads可能会造成最大的问题。



Valgrind会不再有用吗?如果我将Valgrind加载到静态编译的二进制文件中,它会发现错误?或者我们应该维护一个没有静态编译的二进制文件,因此Valgrind继续工作。
strace如何?

我们经常崩溃,因为我们有很大的安装基础,它也是一个遗留应用程序。收集所有共享库变得棘手 - 我需要另一种解决方案。



编辑:固定错字。

解决方案


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



$ b

是的。

然而,与流行的观点相反,静态链接的二进制文件比动态的(至少在Linux上)。



特别是,如果您使用以下任何函数: gethostbyname gethostbyaddr getpwent getpwnam getpwuid (以及更多),您将在链接时收到警告,类似于:

 在静态链接的应用程序中使用'getpwuid'需要在运行时
来自用于链接的glibc版本的共享库。

这个警告意味着如果您的客户拥有不同版本的glibc从链接时使用的glibc安装(即与 系统libc不同),那么 您的程序可能会崩溃。由于这是一个明显比目前更糟糕的情况,我不认为静态链接是一个很好的解决方案。


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.

解决方案

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.

这篇关于静态链接系统库,libc,pthreads,以帮助调试的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆