c++ - 哪些因素决定了用 g++ 构建的二进制文件需要哪个版本的 glibc？

Question

我管理一个综合体 C++ project

我收到现场报告说在一个系统上构建的二进制文件不能在另一个系统上运行系统因为 glibc 版本不匹配。

我只是想验证一下:二进制文件需要的glibc版本是否完全由编译时使用的g++版本决定？

在这种情况下，二进制文件是用 g++ 11 构建的，并在另一个没有安装 g++ 11 的系统上运行。

Answer 1

I just want to verify: is the version of glibc required by the binary completely determined by which version of g++ is used to compile it?

一点也不。运行时所需的 GLIBC 版本由几个因素决定:

1. 链接时使用的 GLIBC 版本。
2. GLIBC 的特性实际使用(这又取决于编译器版本，可能还有编译标志)。
3. 所使用的任何功能的 ABI 是否发生了变化。

In this case, the binary is built with g++ 11

您可以安装g++-11在具有 GLIBC-2.15 的系统和具有 GLIBC-2.31 的系统上。对于非平凡的源代码，生成的二进制文件在运行时可能对 GLIBC 有不同的要求。

参见 this answer了解符号版本控制是如何发挥作用的。

TL;DR:如果您想构建可移植到不同 Linux 发行版的可执行文件或共享库，请选择您愿意支持的最旧 GLIBC 版本，并在系统上构建使用该版本(您不必为此拥有物理机器——VM 或 docker 容器工作查找)。

由于向后兼容性保证，您的二进制文件将在具有相同或更新版本的 GLIBC 的所有系统上运行。

更新:

假设您构建了 libfoo.a在 GLIBC-NN 上，最终用户链接 a.out在 GLIBC-MM 上，其中 MM < NN .

这是一种非常危险的做法:程序可能会悄无声息地破坏它的数据，找到这种破坏的根本原因将非常困难。

现在假设最终用户链接a.out在 GLIBC-MM 上 NN <= MM (根据评论，这是实际情况)，然后运行 ​​a.out在带有 GLIBC-JJ 的系统上，其中 JJ < NN .

在那种情况下，“无声”损坏的可能性会降到最低，但不会完全消除。

考虑以下假设示例(foo() 是您提供的 libfoo.a 的一部分):

struct passwd *foo()
{
   struct passwd *pw = getpwuid(42);
   if (pw->field_a == 123)              // 1
     pw->field_a = 1234;                // 2
   return pw;
}

现在假设在 GLIBC-NN 中 field_a作为 struct passwd 的一部分存在，但在 GLIBC-JJ 中却没有。在这种情况下，点 1上面的程序可能会读取已分配缓冲区的末尾，并在点 2 处读取。它可能写到最后。

注意:上面的程序已经违反了“应用程序不得修改返回值指向的结构”的要求，因此无论如何都有未定义的行为；这只是 GLIBC 不匹配可能如何产生错误的示例。