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

[Rich Felker]

On Tue, Jun 02, 2020 at 10:56:37AM -0500, Rob Landley wrote:
> On 6/1/20 10:56 AM, Eric Molitor wrote:
> > ---
> >  toys/pending/route.c | 46 +++++++++++++++++++++++++++++++-------------
> >  1 file changed, 33 insertions(+), 13 deletions(-)
> 
> FYI route.c doesn't build with musl-cross-make because:
> 
> ~/ccc/sh4-linux-musl-cross/sh4-linux-musl/include/sys/sysinfo.h:10:8: error:
> redefinition of 'struct sysinfo'
>    10 | struct sysinfo {
>       |        ^~~~~~~
> In file included from
> ~/ccc/sh4-linux-musl-cross/sh4-linux-musl/include/linux/kernel.h:5,
>                  from
> ~/ccc/sh4-linux-musl-cross/sh4-linux-musl/include/linux/netlink.h:5,
>                  from
> ~/ccc/sh4-linux-musl-cross/sh4-linux-musl/include/linux/rtnetlink.h:6,
>                  from toys/pending/route.c:50:
> ~/ccc/sh4-linux-musl-cross/sh4-linux-musl/include/linux/sysinfo.h:8:8: note:
> originally defined here
> 
> Builds find with glibc, but not with musl.
> 
> I'm pretty sure this is because glibc does this in sys/sinfo.h:
> 
> /* Get sysinfo structure from kernel header.  */
> #include <linux/kernel.h>
> 
> And if you DON'T do that, including linux/rtnetlink.h along with sys/sysinfo.h
> breaks the build.

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.

With that said it *also* looks wrong that linux/netlink.h is including
linux/kernel.h, when the only purpose of the latter for userspace
seems to be serving as a legacy name for linux/sysinfo.h (to make
glibc happy). linux/netlink.h is doing this to get a definition for
__ALIGN_KERNEL which it uses in excactly one place:

#define NL_MMAP_MSG_ALIGN(sz)           __ALIGN_KERNEL(sz, NL_MMAP_MSG_ALIGNMENT)

Indeed the inclusion was introduced in commit
ccdfcc398594ddf3f77348c5a10938dbe9efefbe, without any regard for the
namespace pollution.

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.

Rich