https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #25 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to r...@cebitec.uni-bielefeld.de from comment #24) > > --- Comment #23 from Iain Sandoe <iains at gcc dot gnu.org> --- > > unpatched GCC master, gcc-9.x, gcc-8.x and gcc-7.5 work for me with any SDK > > >= > > Xcode commandline tools 11.3b. > > I've recently tried both building gcc 8.3.0 (build only) and master > (full bootstrap and test) on macOS 10.14.6 and 10.15.3, each with Xcode > 11.3.1. Both worked *provided the build and target compilers were > configured with the approriate --with-sysroot to account for the lack of > /usr/include and startup objects in /usr/lib*. That's not going to change, I think (at least, the underlying behaviour). We could entertain and implement a change to Darwin's configuration that automatically discovers the /Library/Developer/CommandLineTools .. or /Applications/Xcode... for Darwin versions >= X and complains of fails to configure if those can't be seen (asking for a --with-sysroot=). We can already invoke GCC like "xcrun /path/to/gcc-exe" provided that is not called "gcc" or "g++" it will work to set the SDKROOT which gcc honours from 7.5+. The only irritation is that we can't use 'gcc' or 'g++' in that position, because xcrun places the clang/++ aliases ahead of the GCC in the PATH (even if the GCC install is first) [last time I tried]. ---- There's also an API to obtain the info - but only on 10.15+ and it forces one to install XCode I suspect to use it, I'm not keen on making new dependencies on things outside our control - I'd rather make use of OSS equivalents. > > If there's no additional information I propose we close this PR after > > another > > week. > > I guess that's fine. I think we have the /usr/local/include issue tracked elsewhere.
