链接到旧版本的libc以提供更大的应用程序覆盖率


70

Linux二进制文件通常动态链接到核心系统库(libc)。这样可使二进制文件的内存占用保持很小,但是依赖于最新库的二进制文件将无法在较旧的系统上运行。相反,链接到较旧库的二进制文件将在最新系统上愉快地运行。

因此,为了确保我们的应用程序在分发期间具有良好的覆盖范围,我们需要找出我们可以支持的最旧的libc并将其链接到该二进制文件。

我们应该如何确定可以链接到的最旧版本的libc?

Answers:


90

找出可执行文件中的哪些符号正在创建对不需要版本的glibc的依赖。

$ objdump -p myprog
...
Version References:
  required from libc.so.6:
    0x09691972 0x00 05 GLIBC_2.3
    0x09691a75 0x00 03 GLIBC_2.2.5

$ objdump -T myprog | fgrep GLIBC_2.3
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.3   realpath

查看附属库中的内容,以查看是否可以链接较旧版本的任何符号:

$ objdump -T /lib/libc.so.6 | grep -w realpath
0000000000105d90 g    DF .text  0000000000000021 (GLIBC_2.2.5) realpath
000000000003e7b0 g    DF .text  00000000000004bf  GLIBC_2.3   realpath

我们很幸运!

GLIBC_2.2.5您的代码中请求版本:

#include <limits.h>
#include <stdlib.h>

__asm__(".symver realpath,realpath@GLIBC_2.2.5");

int main () {
    realpath ("foo", "bar");
}

观察到不再需要GLIBC_2.3:

$ objdump -p myprog
...
Version References:
  required from libc.so.6:
    0x09691a75 0x00 02 GLIBC_2.2.5

$ objdump -T myprog | grep realpath
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 realpath

有关更多信息,请参见http://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/?p=103


9
我还要补充一点,通常只有一个或两个符号会导致对新glibc版本的依赖,因此,如果像我一样担心您将不得不列出数百个符号来删除依赖,则不会。
Malvineous

2
Dietlibc也值得一看。
Gearoid Murphy

或者,如果您可以静态链接(即您的代码不是插件,也不会使用插件),则还可以查看musl-libc。我经常发现,带有musl-libc的静态链接程序比其动态链接的glibc对应程序小。
0xC0000022L

@GearoidMurphy大约五年后,此评论在很大程度上帮助了我。:)
Tango Bravo

1
这只是强制链接到较旧的符号版本,而无需考虑创建较新版本的原因。一般而言,这样做可能会遇到各种各样的问题。如果需要使用旧的符号版本,则还需要针对该旧版本的标头进行编译。这种方法可能适用于一些非常简单的调用,这些调用没有指向系统定义的结构的指针,但是仍然不建议使用。
textshell

11

不幸的是,@ Sam的解决方案在我的情况下效果不佳。但是按照他的方式,我找到了解决问题的方法。

这是我的情况:

我正在使用Thrift框架(它是RPC中间件)编写C ++程序。我更喜欢静态链接而不是动态链接,因此我的程序是静态链接到libthrift.a而不是libthrift.so。但是,libthrift.a是动态链接到glibc的,并且由于我的libthrift.a是使用glibc 2.15在我的系统上构建的,因此我的libthrift.a使用glibc 2.15提供的2.14版本的memcpymemcpy@GLIBC_2.14)。

但是问题在于我们的服务器计算机仅具有glibc版本2.5,而该版本仅具有memcpy@GLIBC_2.2.5。它远低于memcpy@GLIBC_2.14。因此,当然,我的服务器程序无法在这些计算机上运行。

我发现这种解决方案:

  1. 使用.symver获取对memcpy@GLIBC_2.2.5的引用。

  2. 编写我自己的__wrap_memcpy函数,该函数直接直接调用memcpy@GLIBC_2.2.5

  3. 链接程序时,将-Wl,-wrap = memcpy选项添加到gcc / g ++。

步骤1和步骤2涉及的代码在这里:https : //gist.github.com/nicky-zs/7541169


1
问题似乎出在上_FORTIFY_SOURCE,在某些优化级别上,它在较新的GCC版本上默认为1。启用该功能后,某些功能将被屏蔽。对我来说,取消定义然后将其重新定义为0可以使上述解决方案起作用(GCC 4.8.4)。
0xC0000022L

10

要以更自动化的方式执行此操作,可以使用以下脚本创建GLIBC中比给定版本(在第2行设置)中更新的所有符号的列表。它创建一个glibc.h文件(文件名由script参数设置),其中包含所有必要的.symver声明。然后,您可以将其添加-include glibc.h到CFLAGS中,以确保在编译中的任何地方都将其拾取。

如果您不使用没有上述包含项而编译的任何静态库,这就足够了。如果您这样做了,并且不想重新编译,则可以使用objcopy创建具有符号重命名为旧版本的库的副本。脚本的第二行至第二行将创建系统版本,该版本libstdc++.a将与旧的glibc符号链接。添加-L.(或-Lpath/to/libstdc++.a/)将使您的程序静态链接libstdc ++,而无需链接大量新符号。如果不需要它,请删除最后两行和该printf ... redeff行。

#!/bin/bash
maxver=2.9
headerf=${1:-glibc.h}
set -e
for lib in libc.so.6 libm.so.6 libpthread.so.0 libdl.so.2 libresolv.so.2 librt.so.1; do
objdump -T /usr/lib/$lib
done | awk -v maxver=${maxver} -vheaderf=${headerf} -vredeff=${headerf}.redef -f <(cat <<'EOF'
BEGIN {
split(maxver, ver, /\./)
limit_ver = ver[1] * 10000 + ver[2]*100 + ver[3]
}
/GLIBC_/ {
gsub(/\(|\)/, "",$(NF-1))
split($(NF-1), ver, /GLIBC_|\./)
vers = ver[2] * 10000 + ver[3]*100 + ver[4]
if (vers > 0) {
    if (symvertext[$(NF)] != $(NF-1))
        count[$(NF)]++
    if (vers <= limit_ver && vers > symvers[$(NF)]) {
        symvers[$(NF)] = vers
        symvertext[$(NF)] = $(NF-1)
    }
}
}
END {
for (s in symvers) {
    if (count[s] > 1) {
        printf("__asm__(\".symver %s,%s@%s\");\n", s, s, symvertext[s]) > headerf
        printf("%s %s@%s\n", s, s, symvertext[s]) > redeff
    }
}
}
EOF
)
sort ${headerf} -o ${headerf}
objcopy --redefine-syms=${headerf}.redef /usr/lib/libstdc++.a libstdc++.a
rm ${headerf}.redef

为什么sort呢?
Otheus

确实不是必需的,如果您想将其检入源代码控制或阻止构建系统重建所有内容,它只会使文件更具可复制性
patstew

objcopy --redefine-syms解决方案实际上不起作用,花了我几个小时才能找到原因。objcopy尝试对给定的符号进行字符串匹配替换,但是符号的版本表示为string。objcopy根本无法在它们上运行-版本在查找表中表示,objcopy 2.20.50不会尝试对其进行修改。曾经 这里一个“默认”的象征符号,可以用这种方式来改变-symbol@@1.2.3可以改变的。
Otheus

我以为我可以正常工作了,但是如果是这样的话,我一定不能正确地测试一下。我并没有最终使用该部分,我决定重新编译我的部门,因为它似乎不太可能引入运行时问题。
patstew

好答案,非常感谢!在您的构建机器比目标机器新时提供帮助。就我而言,我正在为Debian buster(2.28-10)构建最新的Ubuntu焦点(glibc 2.31-0ubuntu9.1)。如果maxver太低,它将产生重定位错误,例如“文件libc.so.6中未定义带有链接时间参考的符号clock_gettime版本GLIBC_2.2.5”,但在maxver正确的情况下(2.20),它将生成工作二进制文件。这确实应该是glibc手册的一部分!
ArticIceJuice

3

glibc 2.2是一个非常普通的最低版本。但是,找到适用于该版本的构建平台可能并非易事。

也许更好的方向是考虑要支持并基于此的最旧的OS。


3
有道理,我只是希望能从机会的分支中摘出一些多汁的低垂果实:-)
Gearoid Murphy,2010年

gnu.org/software/libc说2012年12月25日发行的glibc 2.17是最新版本。2.2如何成为共同的最小值?
musiphil

@DouglasLeeder:哦,对了;我误会了一段时间。:D谢谢!
musiphil
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.