Description of problem: Likely this is a upstream issue, but I find it quite inconvenient that if I build an executable with f33 rust then it can't run on f32 because it Needs GLIBC_2.32. So I need to build on F32 to be able to run on both F32 and F33. How reproducible: 100% Steps to Reproduce: 1. build an executable like hello_world with rust on F33. 2. try to run on F32 Actual results: ./hello_world/main: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by ./hello_world/main) Expected results: I was hoping it would run. Additional info: Do f33 executables really use glibc-2.32 features? F32 executables run fine on F33 of course, so that is a workaround for now.
For "cargo new hello", which creates a simple hello-world executable, the specific symbol I see in "readelf -s" is pthread_getattr_np@@GLIBC_2.32 on F33, versus pthread_getattr_np@@GLIBC_2.2.5 on F32. Rust does need that symbol for stack overflow detection. I found the specific glibc change here: https://sourceware.org/git/?p=glibc.git;a=commit;h=07a73d521988a7fdea1bb3c3b5bbb2b23a0da2e1 However, glibc symbol versioning is a fact of life, so I don't really want to litigate that particular symbol. Any time glibc needs to transition a symbol, for whatever reason, it may use a new version for that change, and you just happened to be caught on this one. But this has always been the way it works when linking with glibc -- you need to compile and link with the minimum version that you want to support, lest you pick up new symbol versions. Rust uses glibc on linux-gnu targets for platform integration, so that caveat still applies to Rust programs too. > F32 executables run fine on F33 of course, so that is a workaround for now. This is not just a workaround -- you always need to build on your oldest target if you want to share binaries. If it has worked otherwise before, that's luck, not policy. I'm reassigning this bug to glibc, but I'm also going to close it as expected behavior.
Thanks, Josh, that makes good sense.