[Toybox] FYI musl's support horizon.

[Rich Felker]

On Thu, Aug 26, 2021 at 03:56:47PM -0700, enh wrote:
> On Thu, Aug 26, 2021 at 2:34 PM Rob Landley <rob at landley.net> wrote:

Rob asked me for some input on this:

> > In my private emails somebody is trying to make the last aboriginal linux
> > release work and the old busybox isn't building anymore because makedev()
> > used
> > to be in #include <sys/types.h> and now it's moved to <sys/sysmacros.h>.
> > (Why? I
> > dunno. Third base.)

This was glibc bug #19239, and clearly needed to be fixed. Generic
lowercase macro names like "major" and "minor" are *extreme* namespace
pollution for a standard header to be doing. sys/sysmacros.h was
always the correct way to get these macros on glibc, but for whatever
reason (compatibility with some ancient historic unices?) glibc was
making sys/types.h include sys/sysmacros.h implicitly, at least under
some profiles.

What made this even worse was that, under BSD or GNU profile
(including by default), glibc's stdlib.h included sys/types.h. This
meant anything using stdlib.h got the namespace breakage.

In commit f552c792c7ce5a560f214e1104d93ee5b0833967 (2011) musl
emulated this glibc behavior in _GNU_SOURCE profile, but commit
a31a30a0076c284133c0f4dfa32b8b37883ac930 (2019) removed it since glibc
had already fixed the problem and pushed applications still depending
on the wrong behavior to fix their stuff.

> the pain of dealing with that pointless deckchair crap with every glibc
> update is one reason why (a) i've vowed never to do that kind of thing
> again in bionic [we were guilty of the same crime in the past, even me
> personally; the most common example being transitive includes] and (b) i'm
> hoping musl will care a bit more about not breaking source compatibility
> .... but realize he's a bit screwed because code expecting glibc might come
> to rely on the assumption that <sys/types.h> *doesn't* contain makedev(),
> say --- i've had to deal with that kind of mess myself too. sometimes you
> can't win.

musl generally does not break source compatibility with sources that
are using things in the documented way. Things that are making
assumptions that are not part of the specified (for standard
interfaces; or "underspecified" for the extension ones, something we
hope to improve with better documentation as time progresses) behavior
can and will break now and then. A big part of the mission and success
of musl, and the systems integrators/distributions using musl, has
been getting stuff like that fixed in a huge number of upstream
packages.

Rich