c++ - 完全静态构建具有所有依赖项(libgcc 等)的应用程序？

Question

我目前正在尝试将我所有应用程序的依赖项编译为静态库。我的动机:

1. 不依赖任何操作系统提供的库以拥有完美可重现的代码库
2. 避免在其他系统上部署时由动态链接引起的问题
3. 在链接不同版本的库时避免运行时冲突
4. 能够为其他操作系统交叉编译

但是，正如我最初担心的那样，我不得不很快地进入兔子洞。我目前坚持使用 OpenCV，我相信还会有更多。但是，我的主要问题是:

1. 是否可以构建完全静态构建的应用程序(例如 libc、ligcc 等？)
2. 是否可以静态链接所有库，但动态链接主要组件(libgcc 等)？
3. 如果不是，是否可以链接静态构建的库(例如 OpenCV)，但通过动态链接(zlib、libc 等)来满足它们的依赖性？
4. 我在互联网上进行了研究，但找不到详细介绍链接内部结构(静态与动态)的综合指南。你知道一本好书/教程吗？一本关于 gcc 的书能让我更进一步吗？
5. 这是一个非常愚蠢的想法吗？

Answer 1

My motivation:

1. Not to rely on any OS provided libraries in order to have a perfectly reproducible code base

2. Avoid issues when deploying on other systems caused by dynamic linking

3. Avoid run-time clashes when linking against different versions of a library

4. Being able to cross-compile for other OS

你的动机都是错误的。

对于 #1，您不需要完全静态的二进制文件。您只需要使用 GNU 链接器提供的 --sysroot 工具链接一组版本控制的库

对于#2，你的动机被误导了。

在 Linux 上，如果目标系统上安装的 libc 与程序构建的(静态)libc 不同，则完全静态的二进制文件可能会以神秘的方式崩溃。也就是说，Linux 上的完全静态二进制文件(与流行的看法相反)明显不如动态链接的二进制文件可移植。人们应该永远不要在 Linux 上静态链接 libc.a。

仅此一点就应该让您放弃这种方法(至少对于任何基于 GLIBC 的系统)。

对于 #3，不要链接不同版本的库(在程序构建时)，这样就不会导致冲突。

对于#4，与#1 相同的解决方案就可以了。