Tracking issue for glibc wrappers that require a relative new glibc

[SteveLauC]

Context

The glibc wrappers of the interfaces listed in this issue are usually added in a relatively new version, which, if used, won't work with an older glibc.

Currently, the minimum glibc version supported by Rust is 2.17.

Interfaces

• memfd_create(): 2.27
• close_range(): 2.34

[SteveLauC]

@asomers, your thoughts on this? Maybe we can try using raw syscalls in order to cope with old glibc, with extra caution. 🤔

[asomers]

I always prefer not to use raw syscalls. I seem to remember that causing a problem before, though. Was it some old RedHat toolchain or something? I think some system refused to compile Nix when there were unresolvable symbols, even though those weren't used. On newer toolchains it isn't a problem though. Do you remember the bug I'm thinking of?

[SteveLauC]

I seem to remember that causing a problem before, though. Was it some old RedHat toolchain or something? I think some system refused to compile Nix when there were unresolvable symbols, even though those weren't used. On newer toolchains it isn't a problem though. Do you remember the bug I'm thinking of?

Yeah, it is this one #1972.

The above issue is considered a bug, but there are also cases where users with old glibc want to use the memfd_create() interface from Nix, e.g., #2146 and #2431 (comment).

[asomers]

So I guess the options are:

• Use raw syscalls
• Feature gate
• Check at build time using bindgen or similar
• Abandon users with older linkers. Do we even know exactly which linkers are affected?

[SteveLauC]

I think we need raw syscalls, to make things work. Can we have some sort of compile-time check for the arguments and return value of raw syscalls, if so, we have the best of both worlds. IIRC, rustix has implemented something like this.

Update: Just gave rustix's repo a quick check, they didn't implement this.