gcc - 为什么针对已安装的glibc编译的程序不能正常运行？

Question

提前致谢。

我的开发环境:

$ cat /proc/version
Linux version 5.4.0-66-generic (buildd@lgw01-amd64-016) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #74~18.04.2-Ubuntu SMP Fri Feb 5 11:17:31 UTC 2021

$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.30
Copyright (C) 2018 Free Software Foundation, Inc.

$ getconf GNU_LIBC_VERSION 
glibc 2.27

$ #my glibc source version is 2.32.9000-development
$ cat ./version.h
/* This file just defines the current version number of libc.  */
#define RELEASE "development"
#define VERSION "2.32.9000"

由于某些原因，我需要修改和测试glibc。我按照这个网站(https://sourceware.org/glibc/wiki/Testing/Builds#Compile_against_glibc_in_an_installed_location)的步骤修改glibc并编写测试程序。

1. 编译 glibc。(配置并制作)
2. 安装glibc。(安装到目录)
3. ...上述网站中的其他步骤。

我成功修改了一些pthread函数并通过了测试(我编写的测试程序可以针对安装glibc进行编译并成功运行)。 ldd 程序。

$ ldd ./exec/1-1.out 
    linux-vdso.so.1 (0x00007ffcbf367000)
    libpthread.so.0 => /home/cjl-target/gnu/install/lib64/libpthread.so.0 (0x00007fcadcea9000)
    libc.so.6 => /home/cjl-target/gnu/install/lib64/libc.so.6 (0x00007fcadcaed000)
    /home/cjl-target/gnu/install/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fcadd2ca000)

如上所示，程序所依赖的共享库均指向glibc安装路径。

但是当我编译消息队列的测试程序(test mq_unlink)并运行它时，失败如下:

./exec/1-1.out: symbol lookup error: /lib/x86_64-linux-gnu/libpthread.so.0: undefined symbol: __libc_vfork, version GLIBC_PRIVATE

检查程序所依赖的库:

$ ldd ./exec/1-1.out 
    linux-vdso.so.1 (0x00007ffce3f72000)
    librt.so.1 => /home/cjl-target/gnu/install/lib64/librt.so.1 (0x00007f0a389a2000)
    libc.so.6 => /home/cjl-target/gnu/install/lib64/libc.so.6 (0x00007f0a385e6000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0a383c7000)
    /home/cjl-target/gnu/install/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f0a38dac000)

如上所示，共享库libpthread.so.0指向系统库。为什么？

我的编译脚本是(来自上面的网站):

# dobuild.sh
SYSROOT=/home/xxx/xxx/xxx #the glibc's installation path
(set -x; \
gcc \
  -L${SYSROOT}/usr/lib64 \
  -I${SYSROOT}/usr/include \
  --sysroot=${SYSROOT} \
  -Wl,-rpath=${SYSROOT}/lib64 \
  -Wl,--dynamic-linker=${SYSROOT}/lib64/ld-linux-x86-64.so.2 \
  -Wall $*
)

当我编译pthread的测试程序时:./dobuild 1-1.c -pthread -Wall

当我编译 mq 的测试程序时:./dobuild 1-1.c -lrt -Wall

另外，令人困惑的是，在mq_unlink的测试程序中调用pthread_create时，编译./dobuild 1-1.c -lrt -pthread，ldd结果显示:所有依赖库都指向已安装的glibc。

我尝试过多种变体，但似乎都不起作用。有什么想法吗？

Answer 1

首先，您应该停止使用ldd——在主机上存在多个GLIBC的情况下，ldd更有可能产生误导而不是阐明问题。

如果您想查看真正加载了哪些库，请执行以下操作:

LD_TRACE_LOADED_OBJECTS=1 ./exec/1-1.out

其次，您几乎不应该在 shell 脚本中使用 $*。请使用 "$@" (注意:引号很重要)。看这个answer .

第三，您观察到的行为很容易解释。要理解它，您需要知道DT_RPATH和DT_RUNPATH之间的区别，描述here .

您可以验证您的二进制文件当前是否正在使用 RUNPATH，如下所示:

readelf -d 1-1.out | grep 'R.*PATH'

您可以通过将 -Wl,--disable-new-dtags 添加到链接命令(这将导致二进制文件使用 RPATH 代替)。

总结一下:

• RUNPATH 影响二进制文件本身的搜索，但不影响二进制文件依赖的任何库。
• RPATH 影响二进制文件及其依赖的所有库的搜索路径。
• 使用RUNPATH，只有当二进制文件直接依赖于它时，才会找到预期的libpthread.so.0，但当依赖于它时则不会libpthread 是间接(通过librt)。
• 使用 RPATH，无论依赖关系是直接还是间接，都会找到预期的 libpthread.so.0。

更新:

If I want to use DT_RUNPATH, how to set the library runpath for librt?

您需要将 librt.so 与 -rpath=${SYSROOT}/lib64 链接。

您可以编辑rt/Makefile，或使用以下命令进行构建:

make LDFLAGS-rt.so='-Wl,--enable-new-dtags,-z,nodelete,-rpath=${SYSROOT}/lib64'

您需要对可能对 GLIBC 其他部分带来传递依赖的任何其他库执行相同的操作。我不知道执行此操作的一般方法，但 setitng LDFLAGS-lib.so='-Wl,-rpath=${SYSROOT}/lib64' 并重建所有内容可能会成功。