mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Daniel Gutson <>
Subject: Re: [musl] musl -- FFS get your shit together, please
Date: Mon, 17 Jul 2023 09:14:42 -0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]

Dear Dave,

    Please file your comments in the issue tracker so they can be addressed
separately, properly assigned, and track their status and therefore be
planned for the next releases.

El lun, 17 de jul de 2023, 03:15, Dave Blanchard <>

> 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???
> 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 amount of duplicated, undocumented, assorted crap is pretty ridiculous
> for a project that's supposed to be a FROM SCRATCH libc implementation! How
> about getting it right from the beginning, with a clean and organized
> implementation, instead of starting off with a random pile of shit? Even
> glibc is better organized, for fuck's sake!
> 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?
> 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??
> 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!
> Dave

[-- Attachment #2: Type: text/html, Size: 2484 bytes --]

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