静态链接libc的正确方法是什么？答案

【问题标题】：What is the correct way to static link libc?静态链接libc的正确方法是什么？
【发布时间】：2019-12-24 01:18:57
【问题描述】：

我在这里和其他论坛上看到了很多问题，建议使用 -static 或有时甚至是 -static -static-libgcc 以及编译参数。这在 Alpine 上永远无法运行，但在 Ubuntu 和 Fedora 上运行良好。

我用 C 写了一个简单的 hello-world 程序，然后编译为gcc -static test.c。生成的二进制文件仍然亮着ldd。看，

$ gcc -s test.c -static
$ ldd ./a.out
    /lib/ld-musl-x86_64.so.1 (0x7f043eae8000)

$ file ./a.out
./a.out: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, stripped

在 Ubuntu 上运行同样的节目：

$ gcc -s test.c -static                   
$ file ./a.out 
./a.out: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=bf6bfa1c78c541ae4e81586bcd050923bca9e34a, stripped

在任何平台上静态链接 libc 本身的正确且一致的方法是什么？这是否与 GCC 本身的编译方式有关？

【问题讨论】：

看来这个问题是 musl-libc 特有的，你同意吗？也许标题应该相应地修改。
@JonathonReinhart 看了答案后，我认为这个问题似乎比 Alpine 或 Ubuntu 更复杂一些。所以我猜标题是正确的。我已经通过示例和解释添加了正确的答案。

标签： gcc linker

【解决方案1】：

我在这里为那些天真地来这里搜索 static link libc 之类的关键字的人回答我自己的问题。

如果这是针对 MSVC，您唯一的选择是 /MT 或 /MTd。但是如果你是来找GCC的，欢迎来到位置无关的代码兔子洞。

GCC 有多种变体，它们针对特定目标进行了修补，或者仅仅因为它们可以修补而被修补。因此，如果您有 GCC 版本 6.0 并希望您的命令行参数产生相同的行为，那么您可能会成为一些糟糕的补丁工作的受害者。

此问题中的某些 GCC 版本强制执行位置无关的可执行文件 (-fPIE -pie) 并默默地忽略此示例中看到的 -static 选项。我想知道这是否应该作为一个错误报告给 Alpine 维护人员。要强制它忽略 PIE，请将 -no-pie 传递给您的 GCC。

$  gcc -no-pie -static test.c

如果你这样做了

$ file ./a.out
/lib/ld-musl-x86_64.so.1: ./a.out: Not a valid dynamic program

有关 fPIE 和 static 如何从 OpenBSD 阅读这些 slides 的详细信息。

【讨论】：

【解决方案2】：

您的 Ubuntu 二进制文件未启用 PIE。如果你将-no-pie 传递给 Alpine 上的 GCC，它的二进制文件同样不会启用 PIE，但它会根据你的需要进行静态链接。

【讨论】：

为什么 PIE 和静态链接相关？

【解决方案3】：

您可能构建得很好，它看起来更像是file 中的一个错误。请参阅此错误报告： https://bugs.astron.com/view.php?id=93

总结：0000093：文件错误地识别 -static-pie 二进制文件

我在构建 QEMU 时遇到了同样的问题，但我被告知上述情况： https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21214#note_156907

【讨论】：