> On 10 Jul 2024, at 16:45, Iain Sandoe <i...@sandoe.co.uk> wrote:
>> On 10 Jul 2024, at 16:25, FX Coudert <fxcoud...@gmail.com> wrote: >> >> I found another useless fixincludes on darwin, but this one was a bit harder >> to diagnose. GCC trunk applies a fix to <stdio.h> on modern Darwin: it is >> stdio_stdarg_h. That fix is actually part of a pair, along with >> stdio_va_list, and they appear to work around issues with some old Unix (or >> BSD?) headers and the definition of va_list. It is not entirely clear to me >> what they fix, but they have been here forever. >> >> They use various bypass mechanisms, but those are fragile. I have no idea if >> the fix is actually needed on any still-supported system, and maybe some >> global reviewer might want to remove it. But for now, I only want to bypass >> the fix on Darwin: it is useless there, and applying it makes our builds >> more fragile (and sensitive to the SDK version). Solaris has already opted >> out years ago, and now we do the same. >> >> To show the madness of this fix, the macOS headers actually contain a >> comment that is supposed to trigger the bypass: >> >> /* DO NOT REMOVE THIS COMMENT: fixincludes needs to see: >> * __gnuc_va_list and include <stdarg.h> */ >> >> This kludge was added to the Apple headers in Libc-391 released around 2004. >> But it recently became ineffective, due to the majority of the content of >> <stdio.h> being moved into <_stdio.h> (which is not covered by fixincludes). >> >> Anyway, the only sane thing to do is to disarm this fix on darwin, as the >> attached patch does. > > Right, if the comment was added in 2004, we have no still-supported OS > versions that are relevant, > >> Tested on aarch64-apple-darwin24, OK to push? > > Yes, OK for trunk, and backports after some bake time, I have reverted the commit with r15-1964-g619f587f68525178 since it breaks bootstrap on supported x86_64 OS versions. We need to revise it and check across the whole supported OS range. thanks Iain
