On Thu, Aug 26, 2021 at 03:56:47PM -0700, enh wrote: > On Thu, Aug 26, 2021 at 2:34 PM Rob Landley <[email protected]> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
