完全静态构建具有所有依赖项（libgcc 等）的应用程序？

Question

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

1. 不依赖任何 OS 提供的库以获得完美可重现的代码库
2. 避免因动态 linking
在其他系统上部署时出现问题
3. 避免运行-当link针对不同版本的库
时发生冲突
4. 能够为其他OS
交叉编译

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

1. 是否可以构建完全静态构建的应用程序（例如 libc、ligcc 等？）
2. 是否可以静态 link 所有库但动态 link 主要组件（libgcc 等）？
3. 如果不是，是否可以 link 对抗静态构建的库（例如 OpenCV），但通过 link 动态构建（zlib、libc 等）来满足它们的依赖性？
4. 我在互联网上进行了研究，但找不到详细介绍 linking（静态与动态）内部结构的综合指南。你知道一本好书/教程吗？关于 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，您不需要完全静态的二进制文件。您只需要 link 使用 GNU linkers

提供的 --sysroot 工具针对一组版本控制的库

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

在 Linux 上，如果安装在目标系统上的 libc 不同于构建程序的（静态）libc，则完全静态的二进制文件可能会以神秘的方式崩溃。也就是说，Linux 上的完全静态二进制文件（与流行的看法相反）显着 不如动态 linked 二进制文件可移植。应该 never 静态 link libc.a on Linux.

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

对于 #3，不要 link 针对库的不同版本（在程序构建时），这样不会导致冲突。

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