Re: [musl] musl -- FFS get your shit together, please

[Rich Felker <dalias@libc.org>]

On Mon, Jul 17, 2023 at 12:01:00PM -0400, Jeffrey Walton wrote:
> On Mon, Jul 17, 2023 at 11:21 AM Rich Felker <dalias@libc.org> wrote:
> >
> > On Mon, Jul 17, 2023 at 01:17:58AM -0500, Dave Blanchard wrote:
> > > There's a lot to like about musl, but damn, there's some absolutely ridiculous aspects also:
> > >
> > > 1) How in the hell are you going to make a MAJOR change like
> > > changing #ifdefs from defined(_LARGEFILE64_SOURCE) ||
> > > defined(_GNU_SOURCE) to just defined(_LARGEFILE64_SOURCE) in a PATCH
> > > level increment, from 1.2.3 to 1.2.4? What the hell is wrong with
> > > you? You just broke my entire build! Yet another patch had to be
> > > created on my end to UNDO this crazy change; the only alternative
> > > was patching half the packages on my system to fix their now-broken
> > > build! Do you know NOTHING about proper versioning???
> >
> > Our versioning system works like this: in x.y.z,
> >
> > - increment of x, likely to never happen, would indicate a completely
> >   different ABI
> >
> > - increment of y indicates a change whereby programs compiled for the
> >   new y, even without use of any new features added in new y, may not
> >   run with an older y. canonical example: time64.
> >
> > - increment of z indicates a change whereby programs built for the new
> >   z should still run on older z (modulo any bugs that might be present
> >   in the older version) as long as they're not using new interfaces
> >   introduced in the new z.
> >
> > All of these conditions are assuming the program used the public
> > interfaces and did not poke at unspecified internals, etc.; if it did,
> > all bets are off and any version change may be fully-breaking to the
> > program.
> >
> > Note that all of these deal with ABI compatibility, not compile-time
> > compatibility.
> 
> To play devil's advocate... If a symbol in Musl disappears, then
> shouldn't that be considered an ABI break? And then, shouldn't it
> require a major or 'x' bump?

Only if that symbol is something that can be linked to as part of
using the published (via the headers) API. If for example you used
__clone, __dl_seterr, __funcs_on_exit, __map_file, __setxid, or any of
the other internal interfaces and one of these changed, it would not
be an "ABI break".

(Note: most of these are hidden nowadays for dynamic linking purposes,
but for the sake of this thought experiment you could think of static
linking your old .o files to a new libc.a and the same "ABI issues"
would apply, without the benefit of visibility protecting you from
being able to reference internal things.)

> It seems like Musl signed that contract when it first published a
> symbol under _LARGEFILE64_SOURCE or _GNU_SOURCE. When the symbol
> disappeared using one or the other define, then the contract was
> broken.

Our _LARGEFILE64_SOURCE explicitly did not/does not use any symbols.
It's purely macro-based at compile time. If you're going to jump in
and argue about something, at least take the time to check the basics
on something like this.

Rich