基于amazonlinux:2编译Rust为何出现GLIBC版本不匹配问题？

问题场景 #

为规避AWS Lambda运行时兼容性问题，使用amazonlinux:2镜像构建Docker编译环境，Dockerfile内容如下：

FROM amazonlinux:2

RUN yum install -y openssl-devel gcc python3 python3-pip zip make
RUN pip3 install awscli aws-sam-cli

# Install Rust toolchain using rustup
RUN curl https://sh.rustup.rs -sSf | sh -s -- -y
ENV PATH="/root/.cargo/bin:${PATH}"

RUN cargo install --list

CMD ["/bin/bash"]

执行部署命令：

docker run -it -v "$(pwd)":/root/project -w /root/project my-rust-project sam deploy

部署完成后Lambda调用失败，报错：

2023-02-27T22:47:41.378-08:00 /var/task/bootstrap: /lib64/libc.so.6:
version `GLIBC_2.25' not found (required by /var/task/bootstrap)

2023-02-27T22:47:41.378-08:00 /var/task/bootstrap: /lib64/libc.so.6:
version `GLIBC_2.18' not found (required by /var/task/bootstrap)

编译容器内执行ldd --version显示为ldd (GNU libc) 2.26，疑问：为何高版本GLIBC编译的可执行文件会依赖更低版本的GLIBC？

原因解析 #

这是GLIBC的符号版本机制导致的：

• 高版本GLIBC会包含低版本引入的符号，编译时如果程序用到了某个在GLIBC 2.18/2.25中新增的函数或符号，链接器会将该符号对应的版本标记写入可执行文件。
• ldd --version显示的是编译系统的GLIBC整体版本，但可执行文件的依赖是针对每个符号的最低GLIBC版本要求，而非系统的最高版本。
• 你的Lambda运行时环境（比如基于Amazon Linux 1的旧版运行时）搭载的GLIBC版本低于2.18，无法提供程序依赖的符号定义，因此触发报错。
• 可通过objdump -T /path/to/bootstrap | grep GLIBC_命令查看可执行文件所有依赖的GLIBC符号版本，明确哪些符号需要2.18或2.25。

解决办法 #

1. 静态编译（推荐） #

使用Musl libc进行静态编译，生成不依赖系统GLIBC的可执行文件：

cargo build --release --target x86_64-unknown-linux-musl

若项目依赖openssl等系统库，需在Dockerfile中添加Musl编译环境支持：

RUN yum install -y musl-tools
ENV CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER=musl-gcc

2. 匹配Lambda运行时的编译环境 #

使用与Lambda运行时一致的环境编译，确保依赖的GLIBC版本匹配：

• 直接使用AWS SAM官方提供的Rust编译镜像：public.ecr.aws/sam/build-rust:latest，该镜像环境与Lambda运行时完全对齐。
• 或在现有Dockerfile中，通过RUSTFLAGS强制Rust编译兼容更低版本的GLIBC：

RUSTFLAGS="-C link-arg=-Wl,--wrap=memcpy -C link-arg=-Wl,--dynamic-linker=/lib64/ld-linux-x86-64.so.2" cargo build --release

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