Rust Applications built on Centos7 cannot run on Centos6

[domibay-hugo]

I have a develop machine with Centos7 where I build little applications to run on Centos7 and Centos6 target machines.
Now trying to run my "hello-world" application on Centos6 and it crashes:

fn main() {
    println!("Hello, world!");
}

$ ./hello-world
./hello-world: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./hello-world)

the target system is:

$ cat /etc/centos-release
CentOS release 6.10 (Final)

the glibc package provides:

$ rpm -q --provides glibc|grep -i "GLIBC_"
libc.so.6(GLIBC_2.10)(64bit)  
libc.so.6(GLIBC_2.11)(64bit)  
libc.so.6(GLIBC_2.12)(64bit)  
libc.so.6(GLIBC_2.2.5)(64bit)  
libc.so.6(GLIBC_2.2.6)(64bit)  
libc.so.6(GLIBC_2.3)(64bit)  
libc.so.6(GLIBC_2.3.2)(64bit)  
libc.so.6(GLIBC_2.3.3)(64bit)  
libc.so.6(GLIBC_2.3.4)(64bit)  
libc.so.6(GLIBC_2.4)(64bit)  
libc.so.6(GLIBC_2.5)(64bit)  
libc.so.6(GLIBC_2.6)(64bit)  
libc.so.6(GLIBC_2.7)(64bit)  
libc.so.6(GLIBC_2.8)(64bit)  
libc.so.6(GLIBC_2.9)(64bit)  

So I am wondering why the Rust Library requires GLIBC_2.14 and cannot run with GLIBC_2.12 ?

Needless to mention that Applications compiled with other Languages do run on both Centos7 and Centos6 systems.

Another Application built with another Compiler on Centos7:

$ ./hello-world_fpc.run
Hello, world!
$ ./hello-world_fpc.run -h
Usage: /path/to/hello-world_fpc.run -h

[gnzlbg]

This repo only provides FFI bindings.

The actually glibc version that gets dynamically linked to the pre-packaged libstd in the x86_64-unknown-linux-gnu components is chosen in rust-lang/rust, so you'd need to ask there why are they using a linux image that uses glibc 2.14 and not some older linux version (probably because libstd needs an API that's only available in glibc 2.14, but maybe there isn't a good reason beyond "that's the image we have and nobody has complained about it until now").

Needless to mention that Applications compiled with other Languages do run on both Centos7 and Centos6 systems.

Those applications might be dynamically linked against a glibc 2.12 or older. You can recompile your application in your system down to libstd using cargo xbuild, and that will have to at least try to link to your system glibc version. A binary compiled against glibc 2.12 is forward compatible with glibc 2.14, so if libstd supports glibc 2.12, then that should work.