https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #39 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Erik Schnetter from comment #38) > (In reply to Iain Sandoe from comment #36) > > (In reply to Jürgen Reuter from comment #35) > > > The latest fix doesn't work. It fails at the darwin-driver.c. So yes, all > > > the files mentioned before have to be modified, asan_mac.cc, > > > sanitizer_mac.cc, > > > sanitizer_platform_limits_posix.cc, darwin-driver.c > > > > that's not how fix includes work; > > the idea is to make a change such that the includes can be used "normally" > > (which isn't 'modify every use site' ;) ) > > > > grep says that ucred.h is included from a *lot* of places in the SDK, so > > "just fixing bootstrap" isn't enough, we need a fix that works when building > > user code too. > > I originally assumed that fixincluded files would come first in the include > search path, so that correcting the offending file prevents all problems. > That doesn't seem to be the case -- only files included from user code seem > to see the fixincluded files, whereas system files don't see them. Is this > correct? If so, that certainly makes it difficult to correct a problem, > since this would require all header files that (transitively) include the > offending header file also need to be fixincluded. I'm sure I misunderstand > something here. no, you haven't missed anything - have you examined the output in gcc/includes-fixed and checked that the changes you expect have been made? you can examine the order of the search paths for the includes (look at the output of gcc -v) > > I note that there is __APPLE_API_STRICT_CONFORMANCE which gates the > > __APPLE_ABI_UNSTABLE .. perhaps this should be investigated? > > I missed this. I'll have a look.