glibc - 为什么 glibc 有 2 个版本的相同功能？

Question

我不太了解glibc的版本控制机制。 在什么情况下，开发人员决定某个函数需要新版本，并且该函数在 glibc 中不再“向后兼容”，需要引入新的 GLIBC_2.X 版本？

对于函数原型(prototype)更改或 API 更改的情况，我理解，但还有哪些原因？

即匹配:

我正在查看 glibc 2.19 上的 readelf 输出，我看到了 2 个版本的 fnmatch:

151: 000bff40   892 FUNC    GLOBAL DEFAULT   12 fnmatch@GLIBC_2.0
152: 000bff40   892 FUNC    GLOBAL DEFAULT   12 fnmatch@@GLIBC_2.2.3

但是当我查看 glibc 的代码时，我发现它们是完全相同的函数:

versioned_symbol (libc, __fnmatch, fnmatch, GLIBC_2_2_3);
#  if SHLIB_COMPAT(libc, GLIBC_2_0, GLIBC_2_2_3)
strong_alias (__fnmatch, __fnmatch_old)
compat_symbol (libc, __fnmatch_old, fnmatch, GLIBC_2_0);
#  endif

那么为什么 fnmatch 有两个版本呢？ 还有哪些其他原因促使开发人员启动功能的“新版本”？

Answer 1

如果 ABI 发生变化，界面也会发生变化，例如内部结构的一些变化可以通过针对旧版本库编译的代码看到。这需要新的版本符号。

默认情况下，编译代码时会选择当前版本。 glibc 还提供了旧版本，允许人们获取使用旧 glibc 版本编译的二进制文件(由供应商提供)并在自己的计算机(具有较新的 glibc 版本)上运行它们。