On 6/2/20 12:53 PM, Rich Felker wrote: > On Tue, Jun 02, 2020 at 12:42:41PM -0500, Rob Landley wrote: >> On 6/2/20 12:25 PM, Rich Felker wrote: >>> This likely needs a new __UAPI_* macro to suppress it. It's likely >>> that nobody has hit it because sys/sysinfo.h is a pretty obscure >>> header and it's usually not included anywhere except uptime(1), etc. >>> Having it in lib/portability.h, rather than just in the files that >>> need it, is probably not a good idea. >> >> It built fine with glibc, which is why it got committed unnoticed. >> >>> I'm not sure how kernel folks will want to fix this, if at all. Once >>> we get an idea of that I can include a patch in mcm for the kernel >>> header that matches what upstream is doing. >> >> Again, builds fine with glibc. I commited a workaround for the musl bug. > > This is not a musl bug. I'm really really REALLY tired of you calling > things musl bugs when they obviously are not.
Sorry. I'm _really_ stressed right now. For context, I'm frustrated that musl-cross-make seems to be reproducing the "forked kernel header" era that Maszur did 15 years ago. Remember when Linux >From Scratch tried to put together a FAQ about it? http://lists.linuxfromscratch.org/pipermail/faq/2004-July/000159.html I had significant problems with it at the time: https://lore.kernel.org/lkml/200412041949.57466....@landley.net/ https://lore.kernel.org/lkml/200412051805.20980....@landley.net/ And checking my old blog entries, I'm reminded that the REASON it got so bad is everybody was using 2.4 headers all through 2.5: https://landley.livejournal.com/766.html https://landley.livejournal.com/8418.html And after 2.6 shipped and people started moving their libc builds to 2.6 headers they found All The Regressions and the kernel guys went "you haven't bothered us about this for YEARS why are you bitching now" and they went "because 2.5 wasn't usable" and this whole thing is part of the reason the kernel stopped doing even/odd development cycles and instead switched to the perpetually stable timed quarterly releases thing. The forked headers were basically just another variant of "everybody's patches are against 2.4, we need to forward port stuff and Dave Jones has a tree backporting stuff to and it's a mess re-unifying and finally getting everybody to trust 2.6" (which took about 2 years if I recall). I had a nontrivial role in ENDING the need for the Maszur header fork and getting proper header support upstream resolved (David possibly Woodward did the heavy lifting, but I was an early adopter testing and sending feedback and bug reports and getting it to work in uClibc and such), and then half my perl removal patches were rewriting the make headers_install infrastructure from scratch so a good chunk of the code that's there to do it now _I_ wrote, and I still get the occasional cc: on patches to it. Now you're returning musl-cross-make to the days of forked headers that need to be independently debugged from upstream. I noticed this time because those headers have nothing for m68k and s390x, so they broke my toolchains. You accepted notification of that bug back in March: http://lists.landley.net/pipermail/toybox-landley.net/2020-March/011536.html But I just pulled musl-cross-make (last updated in April) and the LINUX_VER line in the makefile still git annotates to: 38e52db8 (Rich Felker 2019-12-18 14:29:07 -0500 11)LINUX_VER = headers-4.19.88 (The s390x duplicate dynamic linker definition's still there too.) That was the context within which I hit _this_ problem, which is another aspect of musl's unique refusal to #include kernel headers. Both glibc and bionic do so here, bionic's sys/sysinfo.h has: #include <sys/cdefs.h> #include <linux/kernel.h> I.E. This ONLY breaks on musl. My undestanding of your position on the issue is "that's not a bug, that's a feature". Which is another way of saying it's a choice you made that broke stuff. So I added a workaround for another unique idiosyncrasy in a project that made the also unique choice not to #define _MUSL_. > Rich Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
