c - 依赖共享库的静态库

Question

我创建了一个通信库，它静态链接到几个不同的应用程序中。该库支持通过不同种类的硬件进行通信。供应商通过共享库支持某些硬件。在没有这些硬件的系统上，共享库不可用。

之前我们通过编译通信库和应用程序的双版本来处理这个问题。然而，这不是很实用，所以我考虑使用一个更动态的通信库，如果可用，它会尝试使用 dlopen()/dlsym() 加载供应商库。这似乎运作良好。但问题是，每个使用我的库的人在将他们的应用程序与我的库链接时都需要传递 -ldl 选项。即使这是一个小麻烦，我也想知道通常如何解决这个问题。

是否有可能创建一个自动(在编译时或运行时)引入所需共享库的静态库？

让静态库依赖于共享库被认为是好的做法吗？

编辑:我知道 libtool 可能会解决这个问题，但这仍然会进一步改变所有应用程序的构建过程，我希望避免这种情况。

编辑 2:目标平台主要是 Linux 和 Solaris。 Gcc 作为编译器。

Answer 1

我不了解 Solaris，因此假设我的回答中的所有内容仅适用于 Linux(尽管 pkg-config 也应该在 Solaris 上可用)。

首先，没有支持静态库引入链接时依赖项的方法。对不起。大多数图书馆使用类似 pkg-config 的东西为此 - 也就是说，当您构建时，您将添加到编译器命令行:

gcc `pkg-config --cflags your-library` [...]

当你链接时:

gcc `pkg-config --libs your-library` [...]

请注意，在这种情况下，--libs 参数会产生类似于 -ldl -lyourlib 的输出。 --cflags 参数可能不会产生任何输出，或者它可能会添加一些包含路径。

不过，如果您绝对需要它与 -lyourlib 一起工作，并且您不介意绑定(bind)到 glibc 中不受支持且不稳定的接口(interface)...好吧，libdl 只是一个通过未记录的 vtable 对动态链接器中的一些例程进行瘦包装。如果您查看正在使用的 glibc 版本的 dlfcn/ 目录下的源代码，您应该能够复制它的作用。

但是，libdl 和 ld-linux 之间的接口(interface)是私有(private)的且不稳定 - 它可能会在任何 glibc 版本中发生变化，包括次要版本和错误修复版本。仅当您控制部署的 glibc 版本并准备在必要时重建您的应用程序时才执行此操作。另请注意，如果您的库本身不是 LGPL，那么使用这样的私有(private) API 可能会出现许可问题；不确定 LGPL 的情况如何。