你遇到的是典型的glibc版本兼容问题——作为系统核心库，glibc不同版本间的符号差异会直接导致动态链接时崩溃，尤其是chroot环境隔离不彻底、意外调用主机glibc的情况。下面是几个可行的解决思路，按可靠性和易用性排序：

1. 用容器替代Chroot（最推荐） #

Chroot的隔离性较弱，很容易意外依赖主机的系统库。Docker这类容器工具能提供彻底的环境隔离，完美匹配目标glibc版本：

• 拉取Ubuntu 16.04官方镜像（自带glibc 2.23）：

  docker pull ubuntu:16.04
  

• 运行容器并挂载你的库目录，直接在纯净的16.04环境操作：

  docker run -it --rm -v /path/to/your-library-folder:/host-lib ubuntu:16.04 bash
  

  整个环境完全独立于主机，不会受glibc 2.26的干扰。

2. 确保Chroot环境完全隔离主机库 #

如果坚持用chroot，先排查是否意外依赖了主机的glibc：

• 进入chroot后，检查库的依赖路径：

  ldd /path/to/your-library.so
  

  所有依赖都应该指向chroot内部（比如/lib/x86_64-linux-gnu/...），如果出现主机路径，说明隔离失效。
• 修复方法：
  1. 重新生成chroot内的动态链接缓存：

     chroot ubuntu /sbin/ldconfig
     

  2. 避免挂载主机的系统目录（比如不要用--bind把主机的/lib挂到chroot里）。
  3. 强制使用chroot内的动态链接器运行程序：

     chroot ubuntu /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /path/to/your-program
     

     这样彻底绕过主机的链接器，确保用chroot内部的glibc。

3. 用Patchelf修改库的链接路径 #

如果你的库是动态编译的，可以用patchelf工具修改它的链接配置，强制指向chroot内的glibc：

• 先在主机安装patchelf：

  sudo apt install patchelf
  

• 修改库的动态链接器（对应chroot内的路径）：

  patchelf --set-interpreter /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 your-library.so
  

• 设置库的依赖搜索优先级：

  patchelf --set-rpath /lib/x86_64-linux-gnu your-library.so
  

  处理完成后把库放到chroot里，就能正常加载了。

4. 静态编译目标库（如果可行） #

如果这个库是你自己开发的，或者能拿到源码，直接静态链接glibc，彻底摆脱系统库依赖：

• 编译时添加静态链接参数：

  gcc -o your-library.so your-source.c -shared -static-libgcc -static-libstdc++
  

  注意：静态编译会增大库体积，且部分依赖动态库的功能（比如NSS、DNS解析）可能无法正常工作，需要测试验证。

5. 谨慎升级Chroot内的Glibc（风险较高） #

不推荐，但如果必须在现有chroot里升级glibc到2.26：

• 进入chroot，添加Ubuntu 18.04（bionic）的源：

  echo "deb http://archive.ubuntu.com/ubuntu bionic main" >> /etc/apt/sources.list
  

• 更新并安装指定版本的glibc：

  apt update
  apt install libc6=2.26-0ubuntu2.1
  

  提醒：升级glibc可能导致chroot内的系统工具（如bash、apt）崩溃，因为它们依赖旧版本的glibc符号。操作前一定要备份chroot目录！

排查小技巧 #

• 用strace跟踪崩溃时的系统调用，定位具体哪个库加载失败：

  chroot ubuntu strace -f /path/to/your-program
  

• 查看valgrind的详细日志，确认是否是glibc符号不匹配导致的崩溃。

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