linux - 在运行时加载 Linux 库

Question

我认为 Linux 的一个主要设计缺陷是在以二进制而非源代码形式分发程序时的共享对象 hell 。

这是我的具体问题:我想以 ELF 二进制形式发布一个 Linux 程序，该程序应在尽可能多的发行版上运行，以便我的强制依赖性尽可能低:在任何情况下唯一需要的库是 libpthread， libX11、librt 和 libm(当然还有 glibc)。当我使用 gcc 构建我的程序时，我正在动态链接这些库。

但是，我的程序也可以选择支持 ALSA(声音接口(interface))、Xcursor、Xfixes 和 Xxf86vm 扩展以及 GTK。但是只有当它们在用户的系统上可用时才应该使用这些，否则我的程序应该仍然运行但功能有限。例如，如果 GTK 不存在，我的程序将回退到终端模式。因为我的程序应该仍然能够在没有 ALSA、Xcursor、Xfixes 等的情况下运行。我无法动态链接到这些库，因为如果其中一个库不存在，程序将根本无法启动。

所以我需要手动检查库是否存在，然后使用 dlopen() 一个一个地打开它们，并使用 dlsym() 导入必要的函数符号。然而，这会导致各种问题:

1) 库命名约定:共享对象通常不简单地称为“libXcursor.so”，而是具有某种版本扩展名，如“libXcursor.so.1”，甚至是非常有趣的东西，如“libXcursor.so.0.2000”。这些扩展似乎因系统而异。那么调用dlopen()应该选择哪一个呢？在这里使用硬编码名称似乎是一个非常糟糕的主意，因为名称因系统而异。因此，我想到的唯一解决方法是扫描整个库路径并查找以“libXcursor.so”前缀开头的文件名，然后进行一些自定义版本匹配。但我怎么知道它们真的兼容？

2) 库搜索路径:我到底应该在哪里寻找 *.so 文件？这也因系统而异。有一些默认路径，如/usr/lib 和/lib，但 *.so 文件也可以位于许多其他路径中。所以我必须打开/etc/ld.so.conf 并解析它以找出所有库搜索路径。这不是一件小事，因为/etc/ld.so.conf 文件也可以使用某种 include 指令，这意味着我必须解析更多的 .conf 文件，对可能的文件进行一些检查由循环 include 指令等引起的无限循环。真的没有更简单的方法来找出 *.so 的搜索路径吗？

所以，我的实际问题是:是否有更方便、更简单的方法来实现我想做的事情？创建一个具有一些可选依赖项(如 ALSA、GTK、libXcursor……但没有它也应该可以工作)的 Linux 程序真的那么复杂吗？做我想做的事有某种标准吗？还是我注定要以这种骇人听闻的方式来做？

感谢您的意见/解决方案!

Answer 1

I think a major design flaw in Linux is the shared object hell when it comes to distributing programs in binary instead of source code form.

就系统的创建者而言，这不是设计缺陷；这是一个优势——它鼓励您以源代码形式分发程序。哦，你想卖你的软件？抱歉，这不是 Linux 优化的用例。

Library naming conventions: Shared objects often aren't simply called "libXcursor.so" but have some kind of version extension like "libXcursor.so.1" or even really funny things like "libXcursor.so.0.2000".

是的，这叫做外部库版本控制。了解一下 here .从该描述中应该清楚，如果您在通常会给您 libXcursor.so.1 作为运行时引用的系统上使用 header 编译二进制文件，那么仅您兼容的共享库是 libXcursor.so.1，尝试 dlopen libXcursor.so.0.2000 将导致不可预测的崩溃。

任何提供 libXcursor.so 但不提供 libXcursor.so.1 的系统要么安装损坏，要么与您的二进制文件不兼容。

Library search paths: Where should I look for the *.so files after all?

您不应该尝试使用它们的完整路径 dlopen 这些库中的任何一个。只需调用 dlopen("libXcursor.so.1", RTLD_GLOBAL);，运行时加载器就会在系统适当的位置搜索库。