← Back to context

Comment by _bxg1

7 years ago

Really interesting. I didn't know much about OpenBSD before, nor did I know that Windows/Linux maintain ABI compatibility indefinitely, although it makes sense.

It's also interesting to consider the web as an application platform in this context. It too has an append-only API that places high importance on indefinite backwards-compatibility. However, because that API is dynamic, not binary, the underlying implementation has much more room to maneuver and re-structure without breaking it.

3 comments

_bxg1

Reply
aidenn0  7 years ago

Note that the while the linux kernel does maintain ABI compatibility indefinitely, the same is not true for glibc, so any dynamically linked applications (i.e. most applications in the past 20 years) have very poor ABI compatibility.

  • microtonal  7 years ago

    the same is not true for glibc, so any dynamically linked applications (i.e. most applications in the past 20 years) have very poor ABI compatibility

    Other libraries, sure, but when it comes to glibc, this is false. glibc uses symbol versioning. E.g. a program that uses fork uses a versioned symbol:

        $ nm a.out | grep fork
                 U fork@@GLIBC_2.2.5

    glibc typically ships with functions with the current ABI version and previous ABI versions, so glibc supports programs compiled against many older versions of glibc.

    See:

    https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-...