On Fri, Aug 27, 2021 at 6:56 AM Rich Felker <dal...@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 <r...@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 >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net