【问题标题】:Linking against an old version of libc to provide greater application coverage链接旧版本的 libc 以提供更大的应用程序覆盖率
【发布时间】:2011-05-01 05:58:30
【问题描述】:

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

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

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

【问题讨论】:

    标签: linux linker libc


    【解决方案1】:

    找出可执行文件中的哪些符号正在创建对不需要的 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

    【讨论】:

    • 我还要补充一点,通常只有一两个符号会导致对新 glibc 版本的依赖,所以如果你像我一样担心你将不得不列出数百个符号来删除一个依赖,你不会。
    • dietlibc 也值得一看。
    • 或者如果您可以静态链接(即您的代码不是插件并且不会使用插件),您还可以查看 musl-libc。我经常发现使用 musl-libc 的静态链接程序比动态链接的 glibc 程序要小。
    • @GearoidMurphy 大约五年后,这条评论出现在很大程度上帮助了我。 :)
    • 这只是强制链接到旧的符号版本,而不考虑创建新版本的原因。一般来说,这样做可能会遇到各种问题。如果需要使用旧符号版本,则还需要针对旧版本的标头进行编译。这种方法可能适用于一些非常简单的调用,这些调用没有指向系统定义的结构的指针,但仍然不可取。
    【解决方案2】:

    不幸的是,@Sam 的解决方案不适用于我的情况。但按照他的方式,我找到了自己的解决方法。

    这是我的情况:

    我正在使用 Thrift 框架(它是一个 RPC 中间件)编写一个 C++ 程序。我更喜欢静态链接而不是动态链接,所以我的程序静态链接到 libthrift.a 而不是 libthrift.so。但是,libthrift.a 动态链接到 glibc,并且由于我的 libthrift.a 是在我的系统上使用 glibc 2.15 构建的,因此我的 libthrift.a 使用 glibc 2.15 提供的 memcpy 版本 2.14(memcpy@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

    【讨论】:

    • 问题似乎出在_FORTIFY_SOURCE 上,在某些优化级别的较新 GCC 版本上默认为 1。启用该功能后,某些功能将被屏蔽。对我来说,取消定义并随后将其重新定义为 0 使上述解决方案有效(GCC 4.8.4)。
    【解决方案3】:

    要以更自动化的方式执行此操作,您可以使用以下脚本来创建 GLIBC 中比给定版本(在第 2 行设置)中更新的所有符号的列表。它创建一个glibc.h 文件(文件名由脚本参数设置),其中包含所有必要的.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
    • 这不是必需的,如果您想将文件签入源代码控制或防止构建系统重建所有内容,它只会使文件更具重现性
    • 这个objcopy --redefine-syms 解决方案实际上不起作用,我花了几个小时才找到原因。 objcopy 尝试对给定的符号进行字符串匹配替换,但符号的版本 not 表示为 strings 。 objcopy 对它们根本不起作用——版本在查找表中表示,objcopy 2.20.50 不会尝试修改。曾经。 有一个可以通过这种方式更改的“默认”符号 -- symbol@@1.2.3 可以更改。
    • 我以为我可以正常工作,但如果是这种情况,我肯定没有正确测试它,抱歉。我最终没有使用那部分,我决定重新编译我的 deps,因为它似乎不太可能引入运行时问题。
    • 很好的答案,非常感谢!当您的构建机器比目标更新时提供帮助。就我而言,我正在为 Debian buster (2.28-10) 构建最新的 Ubuntu 焦点 (glibc 2.31-0ubuntu9.1)。如果 maxver 太低,它会产生一个重定位错误,如“符号时钟_gettime 版本 GLIBC_2.2.5 未在文件 libc.so.6 中定义,带有链接时间参考”,但使用正确的 maxver (2.20),它会产生一个工作二进制文件。这应该是 glibc 手册的一部分!
    【解决方案4】:

    glibc 2.2 是一个非常常见的最低版本。然而,为该版本找到一个构建平台可能并非易事。

    可能更好的方向是考虑您想要支持并在此基础上构建的最古老的操作系统。

    【讨论】:

    • 有道理,我只是希望我能从机会的树枝上摘下一些多汁的低垂果实 :-)
    • 嗯? gnu.org/software/libc 说 glibc 2.17 于 2012-12-25 发布,是最新版本。 2.2 怎么可能是一个共同的最小值?
    • @DouglasLeeder:哦,对了;有一段时间我误会了。 :D 谢谢!
    猜你喜欢
    • 2012-07-09
    • 2013-12-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-11-10
    • 1970-01-01
    • 1970-01-01
    • 2023-03-04
    相关资源
    最近更新 更多