[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230717171216.GM4163@brightrain.aerifal.cx>
Date: Mon, 17 Jul 2023 13:12:17 -0400
From: Rich Felker <dalias@...c.org>
To: Dave Blanchard <dave@...lthe.net>
Cc: musl@...ts.openwall.com
Subject: Re: ITT: Nothing but a bunch of excuses and no solutions
On Mon, Jul 17, 2023 at 10:43:59AM -0500, Dave Blanchard wrote:
> 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.
Basically anyone using "semantic versioning" is using their own
variant of it, because in order for it to be meaningful you have to
define the relevant interface boundaries, and those will differ for
different types of software. If you don't like ours, that a "you
problem" not an "us problem".
> > > 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.
Apparently your translation function just randomly picks a new context
when you're wrong. Maybe it's wired up to ChatGPT or something?
*eyeroll*
If you have a complaint about whether/where code is commented, that's
utterly unrelated to whether/where public headers are commented.
> > > 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.
Have fun breaking your system.
> > > 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!
LMAO this is galaxy-tier stuff.
> > 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.
There is no reason to want the old behavior except being unwilling to
fix something that was always wrong.
Any program that uses proper build-time detection of the (nonstandard)
LFS64 stuff works 100% before or after with no change; even the
resulting binaries should not change.
If a program is assuming those interfaces without testing, that's
broken, and breaking build of programs that make wrong/nonportable
assumptions about the standard headers is something musl has done *all
the time* since its inception. This does not harm end users in any
way, because the compiled binaries continue to work, as always.
If you have a build script building affected programs from source, it
may require new patches to fix whatever they're doing wrong. This has
always been the case, for lots of reasons other than LFS64. We
generally make attempts to assess impact and mitigate in cases where
it's expected that a single change/single release might put undue
burden on systems integrators. That's why the LFS64 macros were left
in place under _LARGEFILE64_SOURCE for now -- if you have an existing
integration and need it to continue working for the time being until
things are fixed on the application side, you can simply add
-D_LARGEFILE64_SOURCE to your global CFLAGS and everything works just
like before while you wait for someone else to do free labor and get
your other upstreams patched.
> > 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"!
As I remember it, the affected "GCC code" is not GCC code but the
library side of the sanitizers, which are generally based on poking at
implementation internals and may or may not work. There have been
improvements on them over the past few years, and they may roughly
work at this point, but have a lot of vestigial glibcisms and design
around poking at stuff that's probably not safe to assume.
I'm not sure of the extent to which distros were/are building and
testing them. I am not. So maybe we overlooked that "GCC" was in the
list. But I don't think it would have made a difference knowing this
ahead of time. Nothing was going to get fixed until there was pressure
from a release where the builds break.
> 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.
Apparently our time is free to listen and respond to getting berated
by users... *eyeroll*
Rich
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.
