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

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

Note that all of these deal with ABI compatibility, not compile-time

> 2) Did it occur to anyone involved in this project to maybe actually
> organize and COMMENT the system header files, instead of just
> randomly throwing a random assortment of shit into an .H file and
> calling it good?

The header files intentionally do not contain nontrivial creative

> 3) Why in the hell does musl duplicate/change(!) internal structures
> from Linux kernel headers instead of just #include'ing the damn
> Linux headers (and relevant structures) and be done with it?

Because we are defining the interface between an application and the
standard library functions not between libc and the kernel or the
application and the kernel.

Sometimes the types will be the same; sometimes they *cannot* (e.g.
when the kernel type is wrong or does not meet the specified

Even when the types do match, the Linux uapi headers are generally not

> 4) Would it kill you to add in various simple #defines and such in
> the headers which greatly improve compatibility with GNU code,
> without actually requiring any support in the libc library code??

I'm not sure what this question even means. Are you talking about the
LFS64 stuff again or something else? The LFS64 macros were removed
(by default) because they were a repeated source of breakage that was
*our fault* compiling C++ programs (where GCC makes _GNU_SOURCE the
default), and thereby our responsibility to fix. The only reason they
were ever added to begin with was because of configure scripts wrongly
detecting LFS64 via link-only tests, resulting in failed builds or
(more often) broken binaries when the LFS64 symbols, which were only
there as ABI-compat for glibc-linked code, got used without any
declarations ("implicit function").

The way this was fixed, very little should have broken. From reports
so far, it seems to have been only a very small amount of
Linux-specific code or code that hard-coded "Linux implies LFS64",
most of which already has patches fixing it.

> Between the above, plus the 6-7 "musl addon" support packages
> required to be installed alongside to make my Linux system build
> with musl, at this point I have essentially FORKED musl!
> Musl is clearly not designed with Linux workstation usage in mind!


  parent reply	other threads:[~2023-07-17 15:21 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 [this message]
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
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).