From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5098 invoked from network); 17 Jul 2023 17:12:30 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 17 Jul 2023 17:12:30 -0000 Received: (qmail 17706 invoked by uid 550); 17 Jul 2023 17:12:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 17666 invoked from network); 17 Jul 2023 17:12:26 -0000 Date: Mon, 17 Jul 2023 13:12:17 -0400 From: Rich Felker To: Dave Blanchard Cc: musl@lists.openwall.com Message-ID: <20230717171216.GM4163@brightrain.aerifal.cx> References: <20230717011758.55d20eae6e60835c5c7fe954@killthe.net> <20230717152103.GK4163@brightrain.aerifal.cx> <20230717104359.c0c69ea70adcec47e1429ccc@killthe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230717104359.c0c69ea70adcec47e1429ccc@killthe.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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 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