<div dir="ltr">Mmh, I just switched my dev machine from Alpine to Ubuntu before working on this, normally I would have caught this.<div><br></div><div>Rob, what are your thoughts on using GitHub actions to build toybox on Alpine, Ubuntu and MacOS and running through the test suite? This would have caught this earlier. I'm happy to submit a patch to set this up if it is desired.</div><div><br></div><div>- Eric</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 2, 2020 at 7:48 PM Rich Felker <<a href="mailto:dalias@libc.org">dalias@libc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jun 02, 2020 at 12:42:41PM -0500, Rob Landley wrote:<br>
> On 6/2/20 12:25 PM, Rich Felker wrote:<br>
> > This likely needs a new __UAPI_* macro to suppress it. It's likely<br>
> > that nobody has hit it because sys/sysinfo.h is a pretty obscure<br>
> > header and it's usually not included anywhere except uptime(1), etc.<br>
> > Having it in lib/portability.h, rather than just in the files that<br>
> > need it, is probably not a good idea.<br>
> <br>
> It built fine with glibc, which is why it got committed unnoticed.<br>
<br>
To clarify here, I was talking about why the kernel header clash went<br>
unnotice for so long in the entire ecosysten, not in toybox. There's<br>
never been a report of this before, and it's likely because there are<br>
only 6 kernel headers which include the offending linux/kernel.h, and<br>
none of them are things that would typically be included in the same<br>
file using sysinfo(). This is among tens of thousands of packages.<br>
<br>
That's not to say it's wrong to include both linux/netlink.h and<br>
sys/sysinfo.h, just an explanation of how the bug survived so long.<br>
<br>
> > I'm not sure how kernel folks will want to fix this, if at all. Once<br>
> > we get an idea of that I can include a patch in mcm for the kernel<br>
> > header that matches what upstream is doing.<br>
> <br>
> Again, builds fine with glibc. I commited a workaround for the musl bug.<br>
<br>
I checked out your workaround and it should work fine at present and<br>
for the forseeable future. I'd still like to get this fixed properly,<br>
but that will be a discussion with kernel folks.<br>
<br>
Rich<br>
</blockquote></div>