构建兼容GLIBC 2.17的应用：GLIBC 2.25依赖问题求解

一、可能导致GLIBC 2.25依赖的其他因素 #

• 未排查到的新增系统符号：除了getentropy，GLIBC 2.25还新增了getrandom、部分扩展的pthread_getattr_np等函数，你的代码或静态库如果调用了这些，也会引入依赖。可以用objdump -T myApp | grep GLIBC_2.25命令列出所有关联符号，逐一排查来源。
• 编译工具链的隐性注入：在GLIBC 2.28系统上用gcc编译时，编译器默认可能启用了依赖新GLIBC的优化或辅助功能，比如libgcc_s.so中的新符号，或者链接器自动引入了某些新的标准库依赖。
• 静态库的编译环境污染：你在CentOS7编译的静态库带回主系统后，主系统的头文件、链接器配置可能覆盖了静态库原有的兼容设置，比如openssl的头文件在主系统中定义了HAVE_GETENTROPY宏，导致链接时强制绑定GLIBC的getentropy符号。

二、通过编译参数规避getentropy依赖的可行方案 #

1. 编译openssl时禁用getentropy #

编译openssl时添加-DOPENSSL_NO_GETENTROPY宏，强制openssl放弃使用getentropy，转而使用更兼容的随机数获取方式（比如读取/dev/urandom）：

./config --prefix=/path/to/openssl-static -DOPENSSL_NO_GETENTROPY no-shared
make && make install

这样编译出的libcrypto.a不会依赖getentropy。

2. 用版本脚本限制符号版本 #

编写一个版本脚本version.map，明确只允许使用GLIBC 2.17及更早版本的符号：

{
  global:
    *GLIBC_2.17;
    *GLIBC_2.16;
    *GLIBC_2.15;
    # 按需添加需要的旧版本符号
  local:
    *;
};

编译应用时通过链接参数指定该脚本：

gcc -o myApp myApp.o -Wl,--version-script=version.map libcrypto.a libcurl.a ...

这会过滤掉所有高于GLIBC 2.17的符号引用。

3. 自定义getentropy兼容实现 #

自己写一个兼容GLIBC 2.17的getentropy函数，编译成静态库后优先链接，覆盖系统库的符号：

// getentropy_compat.c
#include <unistd.h>
#include <sys/syscall.h>
#include <errno.h>

int getentropy(void *buf, size_t buflen) {
    if (buflen > 256) {
        errno = EIO;
        return -1;
    }
    // 调用内核系统调用getrandom，GLIBC 2.17未封装但内核3.17+支持
    return syscall(SYS_getrandom, buf, buflen, 0);
}

编译成静态库：

gcc -c getentropy_compat.c -o getentropy_compat.o
ar rcs libgetentropy_compat.a getentropy_compat.o

链接应用时把这个库放在最前面：

gcc -o myApp myApp.o libgetentropy_compat.a libcrypto.a libcurl.a ...

4. 搭建CentOS7交叉编译环境 #

在主系统上安装CentOS7的mingw64工具链（可通过第三方仓库或源码编译），这样既能编译Windows版本，又能保证Linux版本基于GLIBC 2.17编译，从根源避免依赖问题。示例安装命令（以CentOS8为例）：

yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum install mingw64-gcc mingw64-gcc-c++

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