If this threatens a userspace (meaning glibc in particular) change ... [LWN.net]

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

Posted Aug 21, 2025 16:43 UTC (Thu) by davecb (subscriber, #1574)
Parent article: Bringing restartable sequences out of the niche

... glibc is one of the Linux users of versioned interfaces.

Ask them how to support an abi change by versioning the interface that changed, using linker symbols. High-level (and oversimplified!) view in https://leaflessca.wordpress.com/2018/05/31/an-alternativ..., and the real details in David J Brown's proposal, https://www.usenix.org/legacy/publications/library/procee...

to post comments

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

Posted Aug 22, 2025 0:17 UTC (Fri) by quotemstr (subscriber, #45331) [Link] (3 responses)

I wish people wouldn't use ELF symbol versioning. It causes problems the moment you step off of the narrow path of running old binaries AOT-compiled native-code on new systems.

What happens if you call dlsym? What happens if you try to build a program on a new system targeting an old one and pick up the new symbol without realizing it? (glibc refuses to provide a preprocessor macro for targeting older systems.)

Much better to give new functions new names. Don't add a symbol version my_api@2. Just define a my_api2(). It looks uglier in the short term, sure, but saves everyone trouble in the end.

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

Posted Aug 22, 2025 0:29 UTC (Fri) by intelfx (subscriber, #130118) [Link] (2 responses)

> glibc refuses to provide a preprocessor macro for targeting older systems

Perhaps this is a glibc problem rather than a symbol versioning problem?

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

Posted Aug 22, 2025 0:43 UTC (Fri) by quotemstr (subscriber, #45331) [Link] (1 responses)

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.