gcc - 动态链接的 glibc 应用程序 dlopen() 可以是静态链接的 musl 共享对象吗？

Question

我有一个当前与 glibc 动态链接的库。这个库动态加载到一个应用程序中，该应用程序也与 glibc 动态链接。我无法控制应用程序，只能控制共享对象。

但是，有时加载库会导致应用程序获得 SIGKILLd，因为它具有非常严格的实时要求并且相应地设置了 rlimit。用分析器查看这个告诉我，大部分时间实际上都花在了链接器上。所以本质上动态链接实际上太慢了(有时)。嗯，这不是我曾经想过的问题:)

我希望通过生成一个静态链接的共享对象来解决这个问题。但是，谷歌搜索这个问题并阅读多个其他 SO 线程警告我不要尝试静态链接 glibc。但这些似乎是 glibc 特有的问题。

所以我的问题是，如果我要将此共享库与 musl 静态链接，然后让(动态链接的)glibc 应用程序 dlopen 它，那会安全吗?多个libc一般有问题吗？

Answer 1

Looking at this with a profiler tells me that most of the time is actually spent in the linker.

您的分析方法非常有问题。

首先，“链接器”不会在应用程序运行时运行，只有 loader(也称为 rtld，也称为 ld-linux)会运行。我假设您指的不是加载器，而不是链接器。

其次，加载器在启动时确实有一些运行时成本，但由于您调用的每个函数只被解析一次，加载器运行时成本的比例在运行任何可观时间(超过约 1 分钟)的应用程序应该很快接近零。

So essentially dynamic linking is actually too slow (sometimes).

您可以要求加载程序在加载时通​​过使用 -Wl,-z,now 链接器标志链接来解析共享库中的所有动态符号。

if I were to statically link this shared library against musl and then let a (dynamically linked) glibc application dlopen it, would that be safe?

这不仅不安全，而且很可能根本无法工作(大多数琐碎的共享库除外)。

Is there a problem in general with multiple libc's?

将多个 libc 链接到一个进程中会导致无法计数的问题。

更新:

resolving all symbols at load time is exactly the opposite of what I want, as the process gets sigkilled during loading of the shared object, after that it runs fine.

从这听起来您正在使用 dlopen 而进程已经执行时间关键的实时任务。

这不是明智的做法:dlopen(除其他外)调用 malloc，从磁盘读取数据，执行 mmap 调用等等。所有这些都需要锁，并且可以等待任意长的时间。

通常的解决方案是让应用程序在进入时间关键循环之前执行初始化(加载您的库将是其中的一部分)。

由于您无法控制应用程序，您唯一能做的就是告诉应用程序开发人员他们当前的要求(如果这些实际上是他们的要求)是不可满足的——他们必须提供一些方法来执行初始化在进入时间关键部分之前，否则他们将总是冒SIGKILL的风险。让你的库加载更快只会使 SIGKILL 出现的频率降低，但不会完全删除它。

更新 2:

yes, i'm aware that the best I can do is lower the frequency and not "solve" the problem, only try to mitigate it.

你应该看看prelink .它可以大大减少执行重定位所需的时间。这不能保证您选择的预链接地址可用，因此您有时可能仍会收到 SIGKILLed，但这可能是一种有效的缓解措施。