编译跨Debian版本程序时，如何指定libgcc_s.so的加载路径？

我正尝试在Debian Bookworm系统上编译可执行文件，使其能在Debian Bullseye系统运行。我已下载并解压Bullseye的库包到专用目录用于链接，但即便将旧版libgcc_s.so的路径加入运行时路径，系统全局版本仍被优先加载，这是怎么回事？

相关命令输出：

bodqhrohro@debian:~/git/td/build$ ldd tdutils/generate/generate_mime_types_gperf 
tdutils/generate/generate_mime_types_gperf: /home/bodqhrohro/git/glibc/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by tdutils/generate/generate_mime_types_gperf)
tdutils/generate/generate_mime_types_gperf: /home/bodqhrohro/git/glibc/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_ABI_DT_RELR' not found (required by /lib/x86_64-linux-gnu/libm.so.6)
tdutils/generate/generate_mime_types_gperf: /home/bodqhrohro/git/glibc/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.35' not found (required by /lib/x86_64-linux-gnu/libgcc_s.so.1)
tdutils/generate/generate_mime_types_gperf: /home/bodqhrohro/git/glibc/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /lib/x86_64-linux-gnu/libgcc_s.so.1)
        linux-vdso.so.1 (0x00007fffc6be8000)
        libstdc++.so.6 => /home/bodqhrohro/git/libstdc++/usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd49918c000)
        libc.so.6 => /home/bodqhrohro/git/glibc/lib/x86_64-linux-gnu/libc.so.6 (0x00007fd498fb8000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd498ebd000)
        /home/bodqhrohro/git/glibc/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fd499364000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd498e9d000)
bodqhrohro@debian:~/git/td/build$ objdump -p tdutils/generate/generate_mime_types_gperf |grep RUNPATH
  RUNPATH              /home/bodqhrohro/git/glibc/lib/x86_64-linux-gnu:/home/bodqhrohro/git/libstdc++/usr/lib/x86_64-linux-gnu:/home/bodqhrohro/git/libgcc-s1/lib/x86_64-linux-gnu:/home/bodqhrohro/git/libssl/usr/lib/x86_64-linux-gnu
bodqhrohro@debian:~/git/td/build$ ls -l /home/bodqhrohro/git/libgcc-s1/lib/x86_64-linux-gnu/
total 100
-rw-r--r-- 1 bodqhrohro bodqhrohro 100736 Jan 10  2021 libgcc_s.so.1

我尝试使用-static -Wl,-Bdynamic,-lgcc_s,-Bstatic参数，编译成功且该中间工具能在当前系统运行，但ldd显示它不是动态可执行文件。这是预期的工作方式吗？而且这种方法不适用，因为主程序需要动态链接OpenSSL而非完全静态编译。

1. 为什么旧版libgcc_s.so.1未被优先加载？ #

核心问题是你混合使用了Bookworm系统的高版本基础库与Bullseye的低版本libc：

• 从ldd输出可见，libm.so.6加载的是系统全局的Bookworm版本，而非你指定的Bullseye库目录中的版本。
• 系统版本的libm.so.6依赖的libgcc_s.so.1也是Bookworm版本，该版本要求GLIBC 2.34/2.35，但你链接的是Bullseye的GLIBC 2.31，版本不匹配导致报错。
• 动态链接器处理共享库依赖时，会遵循被依赖库自身的搜索路径（而非主程序的RUNPATH），因此系统libm会优先加载系统路径下的libgcc_s，忽略你主程序设置的RUNPATH。

2. ldd显示非动态可执行文件是否符合预期？ #

是预期结果。-static参数默认会静态链接所有库，后续的-Wl,-Bdynamic,-lgcc_s,-Bstatic仅强制libgcc_s动态链接，但其余核心库（如libc、libm、libstdc++）仍会被静态链接。此时程序几乎是静态可执行文件，仅保留了对linux-vdso.so.1的依赖，因此ldd会提示"不是动态可执行文件"。

3. 可行的解决方案 #

方案一：使用Bullseye chroot环境编译

这是最可靠的方式：

• 用debootstrap创建Bullseye根文件系统，进入chroot环境后安装编译依赖，直接在Bullseye环境中编译，确保所有依赖库版本一致，不会出现跨版本冲突。

方案二：使用--sysroot参数指定编译根目录

在Bookworm上编译时，通过--sysroot参数让编译器将Bullseye库目录作为根文件系统，确保所有基础库（libc、libm、libgcc_s等）都从Bullseye目录加载：

• 编译时添加参数：--sysroot=/home/bodqhrohro/git/bullseye-root（替换为你解压Bullseye所有库的根目录，需包含完整的lib、usr/lib等结构）
• 同时指定链接器的搜索路径，确保链接到Bullseye的库而非系统库。

方案三：临时运行测试（仅用于调试）

若仅需临时测试程序在Bullseye库下的运行情况，可通过LD_LIBRARY_PATH强制动态链接器优先加载Bullseye库：

LD_LIBRARY_PATH=/home/bodqhrohro/git/glibc/lib/x86_64-linux-gnu:/home/bodqhrohro/git/libstdc++/usr/lib/x86_64-linux-gnu:/home/bodqhrohro/git/libgcc-s1/lib/x86_64-linux-gnu ./tdutils/generate/generate_mime_types_gperf

但此方法仅适合调试，无法解决编译时的依赖冲突问题，最终发布仍需保证编译环境与目标环境的库版本一致。

内容的提问来源于stack exchange，提问作者bodqhrohro