嘿，我完全懂你现在的困扰——Ubuntu 20.04自带的GLIBC 2.31确实满足不了那个内部程序的要求，而且绝对不要直接替换系统默认的GLIBC，这会搞崩很多系统核心工具（比如ls、sudo），到时候只能用LiveCD救系统。下面给你两个靠谱的解决方案，你可以根据自己的技术熟练度和场景选择：

方案一：编译安装独立的GLIBC 2.34（不干扰系统版本） #

这个方法会把新的GLIBC安装在用户目录下，只给你的目标程序使用，不会影响系统全局：

• 先安装编译必需的依赖包：

  sudo apt update && sudo apt install build-essential bison gcc make
  

• 创建一个单独的编译目录，避免污染系统文件：

  mkdir ~/glibc_build && cd ~/glibc_build
  

• 获取GLIBC 2.34的源码包（你可以从GNU官方渠道下载，解压到当前目录后，进入源码文件夹）
• 配置编译参数，指定安装到用户专属目录（记得替换下面的your_username为你的实际用户名）：

  ../glibc-2.34/configure --prefix=/home/your_username/glibc-2.34 --disable-werror
  

  这里--disable-werror是为了避免编译过程中因警告触发中断，--prefix指定了安装路径，确保不会覆盖系统文件。
• 编译源码（用-j$(nproc)启用多线程加速，效率更高）：

  make -j$(nproc)
  

• 安装编译好的GLIBC：

  make install
  

• 运行你的内部程序时，指定使用这个新的GLIBC：
  你可以临时通过环境变量指定，比如：

  LD_LIBRARY_PATH=/home/your_username/glibc-2.34/lib /path/to/your/internal/program
  

  如果想让程序默认使用这个GLIBC，可以用patchelf工具修改程序的rpath（先安装patchelf：sudo apt install patchelf）：

  patchelf --set-rpath /home/your_username/glibc-2.34/lib /path/to/your/internal/program
  

  这样之后直接运行程序，就会自动加载新的GLIBC了。

方案二：用Docker容器运行（更安全省心） #

如果不想折腾编译，Docker容器是更稳妥的选择——Ubuntu 22.04自带的GLIBC版本是2.35，完全满足2.34的要求，我们可以用这个版本的镜像来运行程序：

• 先拉取Ubuntu 22.04的镜像：

  docker pull ubuntu:22.04
  

• 直接挂载你的程序到容器中运行：

  docker run -v /path/to/your/program:/app/internal_program ubuntu:22.04 /app/internal_program
  

• 如果你的程序还有其他依赖，可以创建一个简单的Dockerfile来配置环境：

  FROM ubuntu:22.04
  # 安装程序需要的依赖包，替换成实际需要的包名
  RUN apt update && apt install -y your-program-dependencies
  # 复制你的程序到容器内
  COPY /path/to/your/program /app/
  # 设置程序启动命令
  CMD ["/app/internal_program"]
  

  然后构建镜像并运行：

  docker build -t internal-app .
  docker run internal-app
  

  这个方法完全隔离宿主系统，不会对Ubuntu 20.04的原有环境造成任何影响，特别适合新手或者生产环境使用。

重要提醒 #

• 再次强调：不要尝试替换系统默认的GLIBC库文件，这会导致系统瘫痪，修复成本极高。
• 如果用编译方案，部分老旧程序可能依赖旧GLIBC的特定特性，此时容器方案会更可靠。
• 所有操作建议先在测试环境验证，没问题再推广到生产环境。

备注：内容来源于stack exchange，提问作者Den Fulcrum89