使用PAR::Packer打包Perl脚本跨Linux运行报GLIBC版本错误如何解决

GLIBC版本不兼容问题本质是高版本系统编译的二进制会默认依赖高版本GLIBC符号，不需要局限在Ubuntu版本范围内找适配，以下两个方案可直接解决当前适配死锁问题：

• 方案1：使用匹配GLIBC版本的RedHat系容器构建（推荐，兼容性最优）
  目标机GLIBC版本为2.17，CentOS 7默认搭载的GLIBC版本恰好为2.17，且属于RedHat系，和公司定制的目标系统二进制兼容性远高于Ubuntu，同时CentOS 7环境完全支持PAR::Packer安装运行，不存在旧Ubuntu的版本兼容问题：
  1. 拉取CentOS 7基础镜像，启动容器时将待打包的Perl脚本目录挂载到容器内
  2. 容器内执行yum install -y perl perl-devel gcc make安装基础编译依赖，再通过cpanm安装PAR::Packer
  3. 容器内执行pp命令完成脚本打包，生成的二进制默认链接GLIBC 2.17，直接拷贝到目标机即可运行，无需额外依赖
  4. 打包完成后可在容器内执行ldd 生成的可执行文件名验证依赖的GLIBC符号版本，确认最高依赖版本不超过2.17即可
• 方案2：静态编译Perl环境，完全剥离系统GLIBC依赖
  如果公司策略限制使用容器，可以在任意高版本环境下手动编译一个全静态链接的Perl解释器，编译时指定静态链接参数，不依赖系统动态GLIBC库：
  1. 下载Perl源码，编译配置时增加-Dccflags='-static' -Dldflags='-static'参数，完成编译安装
  2. 基于这个静态Perl环境安装所有脚本依赖的模块，再安装PAR::Packer
  3. 使用该静态环境下的pp工具打包脚本，生成的二进制不依赖外部系统GLIBC，可在任意x86_64架构Linux环境下直接运行

• 禁止尝试在高版本系统打包后替换目标机GLIBC库，该操作会引发大量符号冲突、段错误等不可预期问题，完全不适合批量部署场景
• 不需要使用低于GLIBC 2.17的环境构建，避免出现反向兼容问题
• 打包完成后务必先在和目标机环境一致的测试节点验证全功能正常，再封装到系统镜像批量部署

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