[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230717104359.c0c69ea70adcec47e1429ccc@killthe.net>
Date: Mon, 17 Jul 2023 10:43:59 -0500
From: Dave Blanchard <dave@...lthe.net>
To: musl@...ts.openwall.com
Subject: ITT: Nothing but a bunch of excuses and no solutions
On Mon, 17 Jul 2023 11:21:04 -0400
Rich Felker <dalias@...c.org> wrote:
> 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.
Translated: you pretend like you are using the same semantic versioning that everyone else is using, except you actually aren't. You don't care about the suffering you create through your creative, self-serving reinterpretation of semantic 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 header files intentionally do not contain nontrivial creative
> content.
Translated: our code is an uncommented, disorganized mess and we love it.
> > 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
> requirements).
>
> Even when the types do match, the Linux uapi headers are generally not
> namespace-safe.
Translated: the end user will need to patch the musl headers to stop defining custom, bespoke, incompatible versions of kernel structures and just include the damn kernel header files so that their system will actually build properly.
> > 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.
Obviously not!
> Are you talking about the LFS64 stuff again or something else?
Maybe you should try building your own Linux distribution so you will get a clue!
> 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").
Translation: the end user will now need to apply heavy patches to his/her system, and/or patch musl 1.2.4 to revert the old behavior, in order to get their damn system to actually build correctly.
> 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.
Ahem, HELLO? How about THIS report that I'm making now where DOZENS OF PACKAGES on my system (starting with GCC!) now need new patches just to build, when they worked fine before? Didn't take me long to see the writing on the wall and nope the fuck out of your "upgrade"!
Oh, but those patches are already *in existence*, you see! Somewhere. All I have to do is spend hours combing the net to find them. My time is free, so that's no problem.
> > 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!
>
> *eyeroll*
Once again: MUSL IS CLEARLY NOT DESIGNED WITH LINUX WORKSTATION USAGE IN MIND!
After further study, having discovered that musl 1.2.4 has not just fucked the header files but also removed weak links for the LFS64 functions from the damn library itself thus breaking various builds and requiring heavy patching to correct, I have permanently reverted to musl 1.2.3 where I will stay indefinitely. It appears this project's maintainers have their heads permanently and irretrievably installed inside their own asshole. I refuse to continue suffering constant headaches of undoing your neverending breaking changes with each PATCH LEVEL version "upgrade."
Dave
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.
