Re: ABI compatibility between versions

[Szabolcs Nagy <nsz@port70.net>]

* Rich Felker <dalias@libc.org> [2019-02-25 19:33:53 -0500]:
> On Tue, Feb 26, 2019 at 12:18:06AM +0100, Alexander Revin wrote:
> > Hi all,
> > 
> > I know this have been briefly discussed here before, but still: does
> > musl guarantee in some way that executable/library compiled against
> > one musl version will work with  another (for example, 1.18 and 1.21)
> > ?
> > 
> > I remember there were concerns against embedding versioning
> > information in musl like glibc does, but is there a way to somehow
> > ensure the stability between releases?
> 
> It guarantees that there is no ABI mismatch. That's not entirely the
> same as guaranteeing that it will work. If the application was relying
> on a bug in an old version to function, or was poking at some
> accidentally-exposed libc internals not defined as a public interface,
> it's possible that updating libc.so will expose this bug in the
> application.
> 
> This is different from the glibc approach, which is to use symbol
> versioning to attempt to retain "bug-compatibility" with the version
> of glibc the application was linked with. Such a system forces new
> application binaries that want to be able to run on systems with old
> glibc to link against the old glibc, and thereby get the buggy
> behaviors even if they're running on a system without the bugs. Myself
> and most of the musl community I'm aware of consider this entirely
> unreasonable, and that's why musl doesn't do it.

i just want to add that glibc makes a distinction as well
between public api contract and implementation internals
and it does not aim to be compatible with anything that
depends on internals (unless there is a strong reason
to do so) so a binary may not work across glibc versions.

other than the bug compatibility, a difference between the
two approaches is that glibc may do certain abi breaking
changes while keeping old binaries work, that musl cant do.
but for this reason a binary compiled against a new version
of glibc is unlikely to work with an older version (which
is why anybody who wants to distribute a binary that works
across different linux distros, compiles against a very old
version of glibc, which of course means lots of old bugs)
while for musl such breakage is much more rare (happens
when a new symbol is introduced and the binary uses that).