[Toybox] FYI musl's support horizon.

[enh]

On Fri, Aug 27, 2021 at 6:56 AM Rich Felker <dalias at libc.org> wrote:

> 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.
>

yeah, we changed that one in 2017:
https://android-review.googlesource.com/c/platform/bionic/+/402242


> > 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.
>

yeah, you've actually helped us a few times by doing that --- you'd be
surprised the negative reaction _we_ sometimes get to that kind of patch :-(


> Rich
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20210903/1cc1452f/attachment-0001.htm>