On Wed, Jun 03, 2020 at 08:49:47AM -0500, Rob Landley wrote:
> 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.
Apology accepted.
> 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?
This very intentionally is not what I'm doing. Use of the sabotage
linux-headers package is merely an optimization, and intended to be
functionally equivalent to the upstream headers. If there are actually
functional changes between them please let me know so I can try to get
it resolved. Because I really really don't want to go that direction.
> 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.
musl does not use kernel headers. It does not require them to build.
This is a standard and completely reasonable policy. It was also
supposed to be glibc policy from the early days (one of the big
improvements over libc5) but they kept randomly breaking it and
locking themselves into instances of breaking it.
In the specific case of sysinfo, we *can't* use the kernel header
because the type does not match. Not for x32 anyway. At the time x32
was created, glibc made the (possibly unconscious) decision to ignore
existing specifications of types, in both standard and linux-specific
interfaces, and replace long with __syscall_slong_t, etc. to match the
x86_64 types. struct sysinfo is such an interface. Note that if you
type "man sysinfo", you get:
struct sysinfo {
long uptime; /* Seconds since boot */
...
This means applications can write:
struct sysinfo si;
sysinfo(&si);
printf("%ld", si.uptime);
But on glibc x32 which uses the x86_64 definition of sysinfo, this is
a type mismatch. (In practice it might not break with printf anyway
but it will break hard in other examples.)
This kind of x32-specific breakage was probably (maybe a small) part
of why nobody ever used x32 anyway. But on musl the work was done to
make it actually work right in hopes that x32 would be useful. The
musl struct sysinfo in sys/sysinfo.h is the documented userspace API,
the sysinfo() function fills it in to match, and any program that's
using the documented API works just as well on x32 as elsewhere.
> So I added a workaround for another unique idiosyncrasy in a project that made
> the also unique choice not to #define _MUSL_.
I don't get why you're repeatedly bothered by the fact that musl did
not do everything the same way as glibc. If we had done so there would
be no point in having musl. The whole premise is that there were a lot
of things in glibc that could/should have done better. Some of them
are fixable and glibc gradually adopts improved approaches from musl
where they are, and where there's consensus that the way musl is doing
it is better. In other instances, they remain different, and *that's
ok*.
Rich
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
