为什么gcc不支持将动态库链接到静态二进制文件

背景如下：第三方提供商为我们提供了一个libveryfancylib.so，在32b中。使用该库的Softaware还有大量其他linux库依赖项（如QT），但它们是开源的，因此静态链接没有问题。目标平台是64b，运行Debian 7

我们可以提供二进制+动态库的程序，没有问题，但我更愿意看到没有依赖项的单个静态二进制

---

所以我的问题是：为什么我不能将动态库链接到静态二进制文件中？我的意思是缺少什么信息，或者只是很少需要的功能->没有实现。

这是因为动态库和静态库是两种不同的东西。静态库只是对象文件的存档（很像zip存档）。动态库更像是一个可执行程序

---

因此，您不能将任何内容真正链接到静态库中，只能添加更多的对象文件。

有一些MS Windows程序可以这样做，例如和

在开源世界中，开发这样一个工具并没有太大的动机，因为您总是可以从源代码处重新编译（但当然也有可能是某个地方的人做的）

我们可以提供二进制+动态库的程序，没有问题，但我更愿意看到没有依赖项的单个静态二进制

你想解决的问题是什么

您可以遵循Linux上大多数商业应用程序的模式：将可执行文件、共享库和其他资源放在一个目录中（可能有子目录）。当根据这些共享库链接可执行文件时，将

-Wl，-rpath，'$ORIGIN'

（在make use

-Wl，-rpath，'$$ORIGIN'

中）传递到链接器，以便在启动应用程序时，运行时链接器在可执行文件所在的同一目录中查找所需的共享库

---

然后归档该目录并将其交给用户。

是的，它们具有不同的性质，但既然字节码和符号表都在那里，那到底是什么呢阻止我从动态库中生成静态二进制文件（可执行！）。我的意思是，我可以做dlopen包装，这应该可以很好地工作，对吗？@susundberg动态库更像是一个可执行文件，包含数据和代码段等。静态库是一个存档，同样更像是zip或tar存档。静态库不包含数据或代码段，没有ELF（在例如Linux上）头，没有任何重新定位信息，也没有符号列表，只有存档中的目标文件列表。@JoachimPileborg:如果动态链接器有足够的信息连接所有内容，创建等效对象文件的静态工具也应如此；仅仅因为我们不能重新创建原始的对象文件（如果有足够的调试信息可用，我们可能会这样做），并不意味着我们不能得到操作上同样好的东西……尽管这是可能的。GCC可能不支持它，因为需要许可。从法律角度讲，针对动态库的链接和针对静态库的链接是两件不同的事情。所以我的猜测是，如果你是所有人，你可以通过编译你的源代码来创建任何你想要的库。但只有动态库可能意味着您要做一些不太合法的事情。只是猜测一下……是否可以将so文件与可执行文件打包，然后使用dlopen或类似的工具动态加载它？只是想…是的，在库中使用dlopen wrapper应该可以解决这个问题——它可以自动生成python脚本生成wrapper.c，但问题是，为什么不首先在编译器中这样做呢？你不能向第三方索要一个静态库吗？你当然是对的，您所建议的是我们现在正在使用的更好的解决方案，但它并没有回答我试图问的问题：“为什么gcc不将动态库链接到一个静态可执行文件中”--这是如建议的那样，许可问题，还是仅仅是开发人员对此类功能缺乏兴趣，或者甚至是技术上的“不能做”呢（我想不是）。澄清一下：你说我的问题的答案是“gcc不支持这样的功能，因为不需要该功能”@susundberg：正确；这对开源软件来说不是问题，商业供应商可能反对有人弄乱他们的二进制blob，而自由软件运动无论如何都希望阻止使用封闭源代码软件