不幸的是，你不能。不是真的，而且不一致。这是任何动态链接到GLIBC的二进制文件的问题。你可以尝试setting up multiple GLIBC versions并链接到一个，或者你可以尝试patching the resulting binary，但它不一致，不切实际。
那么，有哪些切实可行的选择呢？
1.静态编译
通过使用MUSL而不是GLIBC，我们可以静态编译。
要使用rustup安装MUSL目标（假设x86_64体系结构）：

$ rustup component add rust-std-x86_64-unknown-linux-musl

要在编译时使用它：

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

这是迄今为止最简单的方法，但并不总是有效，特别是在使用本机库时，除非它们也可以静态编译。
1.创建具有较旧版本的VM
这是一种常见的方法。通过使用带有过时的GLIBC符号的操作系统，二进制文件将具有与之兼容的GLIBC符号。
1.使用Docker容器
在我看来，这可能是最方便的方法。如果你有Docker，你可以用一个包含旧GLIBC的容器编译你的项目。查看Rust容器的README以获得编译说明。下面的命令将使用Rust 1.67和GLIBC 2.28（buster自带）编译一个项目：

$ docker run --rm --user "$(id -u)":"$(id -g)" -v "$PWD":/usr/src/myapp -w /usr/src/myapp rust:1.67-buster cargo build --release

我在Ubuntu 22.04上编译了这个程序，并在Ubuntu 20.04上测试了它。
为了进一步测试，我确保二进制文件依赖于另一个动态库（OpenSSL），下面是使用Docker容器编译后ldd ./mybinary的结果：

$ ldd ./mybinary 
    linux-vdso.so.1 (0x00007ffd98fdf000)
    libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fe49e248000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe49e22d000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe49e223000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe49e200000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe49e0b1000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe49e0ab000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe49deb7000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe49ea30000)

这是没有容器时的样子：

$ ldd ./mybinary
    linux-vdso.so.1 (0x00007ffd5d7b7000)
    libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fe85564c000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe85562c000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe855545000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe85531d000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe855f98000)