mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <>
To: Jeffrey Walton <>
Subject: Re: [musl] musl -- FFS get your shit together, please
Date: Mon, 17 Jul 2023 12:55:30 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Jul 17, 2023 at 12:01:00PM -0400, Jeffrey Walton wrote:
> On Mon, Jul 17, 2023 at 11:21 AM Rich Felker <> 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.


  parent reply	other threads:[~2023-07-17 16:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-17  6:17 Dave Blanchard
2023-07-17  7:20 ` (GalaxyMaster)
2023-07-17 12:14 ` Daniel Gutson
2023-07-17 15:21 ` Rich Felker
2023-07-17 15:43   ` [musl] ITT: Nothing but a bunch of excuses and no solutions Dave Blanchard
2023-07-17 15:50     ` Joakim Sindholt
2023-07-17 17:12     ` Rich Felker
2023-07-17 17:23     ` Laurent Bercot
2023-07-17 16:01   ` [musl] musl -- FFS get your shit together, please Jeffrey Walton
2023-07-17 16:10     ` Joakim Sindholt
2023-07-17 16:55     ` Rich Felker [this message]
2023-07-17 15:32 ` Markus Wichmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).