[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Feb 2019 10:58:38 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: Alexander Revin <lyssdod@...il.com>
Subject: Re: ABI compatibility between versions
* Rich Felker <dalias@...c.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).
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
