Bug 1889646 - rust executables NEED GLIBC_2.32
Summary: rust executables NEED GLIBC_2.32
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Carlos O'Donell
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-20 09:55 UTC by Jens Petersen
Modified: 2020-10-21 09:33 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-20 16:59:04 UTC
Type: Bug


Attachments (Terms of Use)

Description Jens Petersen 2020-10-20 09:55:33 UTC
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.

Comment 1 Josh Stone 2020-10-20 16:59:04 UTC
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.

Comment 2 Jens Petersen 2020-10-21 09:33:14 UTC
Thanks, Josh, that makes good sense.


Note You need to log in before you can comment on or make changes to this bug.