He meant GLibC function, not syscall...

Posted Nov 30, 2010 22:56 UTC (Tue) by khim (subscriber, #9252)
In reply to: ABI backward-compatibility is the trick... by madscientist
Parent article: The kernel and the C library as a single project

This is good example: sched_setaffinity(2) had two arguments before 2.3.4. If you'll take the old program which uses this version - you'll be unable to compile it today. BUT! If you'll take binary of old version of program compiled with old version of GLibC - it'll run with new one just fine because today GLibC offers two interfaces of sched_setaffinity(2) and selects them automatically depending on what the calling program expects.

GLibC maintains stable ABI - and it's very good at that (documented "undefined" behavior is exception, of course). Yet it does not maintain stable API! This experience is so alien compared to what other libraries are doing that it takes some time to wrap up the mind around the concept.

ABI == important; API == not so much...

Posted Nov 30, 2010 23:21 UTC (Tue) by madscientist (subscriber, #16861) [Link]

Yes, I agree... exactly why my comments were all discussing ABI backward-compatibility. Your example of the sched_setaffinity(2) call is, as you say, a great example of my point... ensuring that a backward-compatible ABI is available involves a lot of tricky footsie-playing with the linker etc.

API compatibility is a completely different animal: if you're going to use Linux-specific APIs then I suppose you just have to fix your code if they change in the future. If you don't want to do that, restrict yourself to POSIX and other standard APIs. I don't really worry about this, to be honest.

He meant GLibC function, not syscall...

Posted Dec 1, 2010 10:57 UTC (Wed) by Yorick (guest, #19241) [Link]

As you note, the ABI stability only goes in one direction. Someone who wishes to distribute a binary that will work on systems of varying age will have to chose between:

Building his program on a system with the oldest possible libc
Linking to libc statically
Distribute the (dynamic) libc used in the build
Keeping an old build environment somewhere and be careful not to use /usr/lib, /usr/include and so on

None of these solutions are perfect. In some ways, the Unix tradition of providing a "canonical" set of include and lib files in a prominent place, /usr, and a compiler that is configured to use these files by default, makes this harder than it would on a platform where development tools are installed separately and explicitly in a user-specified location.

He meant GLibC function, not syscall...

Posted Dec 1, 2010 14:14 UTC (Wed) by paulj (subscriber, #341) [Link]

It's not alien, it's solid engineering. Further, it takes attention to detail and work to maintain ABIs, which can be boring and unsexy - which is not what a lot of evening/weekend hackers are interested in. So likely most of this work is being done by commercial distros in response to customer demand.

Further, even for the API, there are ways to offer multiple versions of those. You can categorise your APIs in various, including with levels. Applications can then *choose* to explicitly depend on certain APIs or they can choose not to and use whatever the default API is - some applications will do that through laziness or ignorance.

All boring and hard engineering work, but it's what widely deployed (in space and, especially, time) systems tend to have to acquire.