[Pre-RFC] target-glibc: Proposal to add native support for GLIBC versions for the -gnu targets

nikkon-dev:

Add first-class support to rustc and cargo for declaring a binary's glibc deployment target — the oldest glibc release the binary is required to run on.

I support this idea in principle, but there's a major problem with it:

At build time, rustc synthesizes versioned glibc stub shared libraries containing only symbols introduced at or before the requested version, and points the linker at them; the resulting ELF's VERNEED entries cannot exceed the deployment target. The binary then loads on any host with that glibc version or newer.

It is not even remotely that simple. People keep thinking it's that simple because there are a bunch of cases where it'll work by accident, but usually when glibc adds a new version for one or more of its public symbols, it's because, at the assembly-language level, you need to call the new version differently than the old one. The difference is invisible at the C level, because the header files shipped with glibc-2.X tell the C compiler how to call all the @GLIBC_2.X symbols correctly. But rustc would have to know what the difference is, for every glibc symbol that has multiple versions, and that's a big reverse engineering job. Way too big, IMHO, to ask the rust team to take on all by themselves.

If you're serious about this, I'd actually recommend you pursue the idea through the glibc project. Propose addition of a feature selection macro (-D_GLIBC_DEPLOYMENT_TARGET=2.NN) which, if you set it, you get machine code targeting that version of glibc -- as you say, works exactly the same way as MACOSX_DEPLOYMENT_TARGET. I think they'll be at least a little receptive to the idea, although they will probably expect you to do all the work yourself and/or find a way to get people paid to do that work (e.g. a Sovereign Tech Fund grant)

Once that work is done, the libc crate will be able to expose it via cargo features, without needing to grovel through glibc's entire sources and change history to figure out what the actual difference between how you call timer_create@GLIBC_2.3.3 and how you call timer_create@GLIBC_2.34 is, multiply by 2,400 public symbols.

Besides that, a couple smaller notes:

Users opt in via either a target-tuple suffix (--target x86_64-unknown-linux-gnu.2.28)

You shouldn't make up target tuple variations without coordination across the entire ecosystem of programs that use target tuples.

nikkon-dev:

This is written by me using AI tools based on the MVP implementation I tried. Actually, that was assisted with multiple AI models, agents, and tools.

Please don't do this anymore. Please don't use AI in any way to "help" you write anything you want other people to read.

For a whole lot of reasons, but the most relevant one right now is that the overwhelming majority of people in this forum, and indeed the overwhelming majority of people working on open source software, are going to stop reading and forget about your proposal the moment they realize they're reading something that wasn't written by a human. It's simply not a good use of their time.

Another very important reason for this proposal is that I have seen several blog posts describing how to do the "just call the old symbol" that your AI-assisted MVP implementation does, without any awareness of what can go wrong. And that means what you have probably hits all the cases where "just call the old symbol" works by accident, and none of the ones where it'll appear to link correctly but then when you actually try to run the program it'll fail to load, crash, corrupt memory, or worse. And that, in turn, has led you to underestimate how much work it's going to be to implement your proposal correctly.

Of course you might have made the same mistake if you'd set out to do the MVP entirely by hand, but there's a better chance that you would have noticed at least some of the problem cases.