On 3/12/20 1:15 AM, Florian Weimer wrote: > * Vineet Gupta via Libc-alpha: > >> On 3/11/20 1:19 PM, Zack Weinberg wrote: >>> So I withdraw my objections to your original patch. We can always put >>> sys/sysctl.h back in the future if someone does the work to write the >>> emulation. >> >> My 2 cents. Can we _not_ remove the header per-se. This can certainly cause >> arbitrary packages to build time fail (vs. runtime failure from sysctl returning >> -1 or some such). Propagation of such fixes in build systems it may take a while. >> Consider my personal woe with stime removal in context of Buildroot/busybox. >> Despite them fixed in busybox not all moving parts are aligned still and we have >> to carry such patches locally to be able to even build glibc 2.31+ there. > > Why aren't those patches upstream yet? (I'm not blaming you, I'm just > trying to understand what is going on.) Its mostly logistics. The fixes in busybox was done early but there was no release (atleast not until I last checked) so buildroot couldn't just bump the package version. One of my colleagues did send the "patches" to fixup buildroot instead (essentially backport busybox patches in BR itself) and that got stuck in the machinery due to some other things. > Are you in a special position becaue you have to use a newer glibc for > your port, and everybody else using this distribution is sticking with > an older glibc? Thats exactly the case here so I'm in a special situation indeed. Upstream BR is still with 2.30.x and I needed to test glibc 2.31+ for ARC upstreaming. > glibc's approach to removals is inconsistent at best. stime was never > deprecated and removed directly, for example. There is also the issue > that configure scripts ignore deprecation warnings, which then can > lead to build issues later one, something that does not happen with > removed interfaces (which are obviously not detected by configure > scripts). > > And specific to sysctl, the removal of the header and function > actually fixes bugs in a few packages. _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
