If this threatens a userspace (meaning glibc in particular) change ...

Posted Aug 22, 2025 0:43 UTC (Fri) by quotemstr (subscriber, #45331)
In reply to: If this threatens a userspace (meaning glibc in particular) change ... by intelfx
Parent article: Bringing restartable sequences out of the niche

People look to glibc for inspiration on how to use symbol versions in general, and what glibc does is wrong and broken. And no, "just compile on an old docker image" isn't a solution either: what if I want to write a program that *conditionally* uses new functionality? If I compile against old glibc headers, I don't see definitions of the new functionality. If I compile against new glibc headers, I can't run on older systems. The whole situation sucks. The whole problem is avoided by simply not overloading function by version.

How do you solve the problem of shipping bugfixes that might break older versions e.g. the infamous memcpy direction problem? Use what macOS, Windows, and Android do: compatibility versions embedded in the binary manifest.

If this threatens a userspace (meaning glibc in particular) change ...

Posted Aug 23, 2025 1:42 UTC (Sat) by comex (subscriber, #71521) [Link]

macOS does do runtime checks based on compatibility versions, but it also does something more sophisticated.

There's a compiler flag to specify the minimum OS version you need to run on. Meanwhile, every declaration in every system header is marked with a minimum OS version, so you get an error if you accidentally use a newer function (this can be disabled for functionality you want to use conditionally). In more subtle cases, header files can manually check the target version with #if and change their behavior, though this is rarely done.

The goal is that you can always use the latest SDK, even if you are targeting an old OS version (though there is a limit to how far back you can go).

I think glibc would be well-served if it adopted a similar scheme.