[Toybox] [PATCH 1/4] Implement hostname lookups in display_routes

[Rob Landley]

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.rob@landley.net/
  https://lore.kernel.org/lkml/200412051805.20980.rob@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