通过Jenkins导出LD_LIBRARY_PATH为Gradle配置glibc 2.14无效问题

我之前在维护类似的RHEL6构建集群时遇到过完全一样的问题——用EnvInject全局注入LD_LIBRARY_PATH后，Gradle启动直接卡住。根源在于EnvInject会把环境变量加到Jenkins的全局进程环境里，而Jenkins本身依赖系统默认的glibc 2.12运行，修改路径后会导致动态链接库加载冲突，甚至影响Jenkins本身的稳定性。

下面是我验证有效的分步解决方案，既满足单个Android项目的glibc 2.14需求，又不影响其他项目：

1. 安装独立的glibc 2.14到非系统目录 #

首先要在构建机器上单独部署glibc 2.14，绝对不能覆盖系统默认的glibc 2.12（会搞崩整个系统）。推荐编译源码安装到自定义路径：

# 下载glibc 2.14源码
wget https://ftp.gnu.org/gnu/glibc/glibc-2.14.tar.gz
tar xzf glibc-2.14.tar.gz
cd glibc-2.14
mkdir build && cd build

# 配置编译参数，指定安装路径为/opt/glibc-2.14，禁用sanity检查适配RHEL6
../configure --prefix=/opt/glibc-2.14 --disable-sanity-checks
# 编译并安装
make -j$(nproc)
make install

安装完成后，/opt/glibc-2.14/lib目录下会有glibc 2.14的所有核心库文件。

2. 为目标Jenkins Job局部设置环境（禁用EnvInject） #

不要用EnvInject全局注入环境变量，而是在该Android项目的Jenkins构建步骤中临时设置仅当前构建进程生效的环境变量：

方法一：在Shell脚本中临时指定LD_LIBRARY_PATH #

在Jenkins的「Execute shell」步骤开头添加：

# 临时将glibc 2.14的库路径加到最前面，保留系统默认路径
export LD_LIBRARY_PATH=/opt/glibc-2.14/lib:$LD_LIBRARY_PATH
# 执行Gradle构建
./gradlew clean assembleRelease

这种方法简单直接，但如果遇到Gradle启动时动态链接器仍优先加载系统库的情况，可以尝试下面的方法二。

方法二：修改Gradle Wrapper的动态链接器（更可靠） #

如果直接设置LD_LIBRARY_PATH不生效，说明系统默认的ld-linux动态链接器无法找到glibc 2.14的库，可以用patchelf工具修改Gradle Wrapper的ELF文件，强制指定使用glibc 2.14的链接器：

# 先安装patchelf（RHEL6可从EPEL源安装）
yum install patchelf -y

# 修改gradlew的动态链接器
patchelf --set-interpreter /opt/glibc-2.14/lib/ld-linux-x86-64.so.2 ./gradlew
# 设置rpath，让gradlew优先加载指定路径的库
patchelf --set-rpath /opt/glibc-2.14/lib:$ORIGIN/lib ./gradlew

修改完成后，直接在Jenkins Job中调用./gradlew即可，无需额外设置环境变量——因为gradlew本身已经被配置为使用glibc 2.14的链接器和库路径。

3. 避免Gradle Daemon干扰 #

如果该项目使用了Gradle Daemon，建议在项目的gradle.properties中添加：

org.gradle.daemon=false

或者指定独立的Daemon目录，防止其他使用glibc 2.12的项目复用该Daemon进程，导致冲突。

验证其他项目不受影响 #

完成配置后，运行其他项目的构建任务，确认它们依然使用系统默认的glibc 2.12正常构建——因为我们的修改仅针对单个Job的构建进程，没有改变系统全局环境。

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