<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 27, 2021 at 6:56 AM 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 Thu, Aug 26, 2021 at 03:56:47PM -0700, enh wrote:<br>
> On Thu, Aug 26, 2021 at 2:34 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<br>
<br>
Rob asked me for some input on this:<br>
<br>
> > In my private emails somebody is trying to make the last aboriginal linux<br>
> > release work and the old busybox isn't building anymore because makedev()<br>
> > used<br>
> > to be in #include <sys/types.h> and now it's moved to <sys/sysmacros.h>.<br>
> > (Why? I<br>
> > dunno. Third base.)<br>
<br>
This was glibc bug #19239, and clearly needed to be fixed. Generic<br>
lowercase macro names like "major" and "minor" are *extreme* namespace<br>
pollution for a standard header to be doing. sys/sysmacros.h was<br>
always the correct way to get these macros on glibc, but for whatever<br>
reason (compatibility with some ancient historic unices?) glibc was<br>
making sys/types.h include sys/sysmacros.h implicitly, at least under<br>
some profiles.<br>
<br>
What made this even worse was that, under BSD or GNU profile<br>
(including by default), glibc's stdlib.h included sys/types.h. This<br>
meant anything using stdlib.h got the namespace breakage.<br>
<br>
In commit f552c792c7ce5a560f214e1104d93ee5b0833967 (2011) musl<br>
emulated this glibc behavior in _GNU_SOURCE profile, but commit<br>
a31a30a0076c284133c0f4dfa32b8b37883ac930 (2019) removed it since glibc<br>
had already fixed the problem and pushed applications still depending<br>
on the wrong behavior to fix their stuff.<br></blockquote><div><br></div><div>yeah, we changed that one in 2017: <a href="https://android-review.googlesource.com/c/platform/bionic/+/402242">https://android-review.googlesource.com/c/platform/bionic/+/402242</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> the pain of dealing with that pointless deckchair crap with every glibc<br>
> update is one reason why (a) i've vowed never to do that kind of thing<br>
> again in bionic [we were guilty of the same crime in the past, even me<br>
> personally; the most common example being transitive includes] and (b) i'm<br>
> hoping musl will care a bit more about not breaking source compatibility<br>
> .... but realize he's a bit screwed because code expecting glibc might come<br>
> to rely on the assumption that <sys/types.h> *doesn't* contain makedev(),<br>
> say --- i've had to deal with that kind of mess myself too. sometimes you<br>
> can't win.<br>
<br>
musl generally does not break source compatibility with sources that<br>
are using things in the documented way. Things that are making<br>
assumptions that are not part of the specified (for standard<br>
interfaces; or "underspecified" for the extension ones, something we<br>
hope to improve with better documentation as time progresses) behavior<br>
can and will break now and then. A big part of the mission and success<br>
of musl, and the systems integrators/distributions using musl, has<br>
been getting stuff like that fixed in a huge number of upstream<br>
packages.<br></blockquote><div><br></div><div>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 :-(</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rich<br>
</blockquote></div></div>