On Sun, Oct 13, 2019 at 4:22 PM Ken Cunningham < ken.cunningham.web...@gmail.com> wrote:
> >* I did not want to touch that at this point. The gcc bug report is still > *>* open, as far as I can see. > *>>* If someone wants try a build using —with-build-sysroot instead, they are > *>* very welcome to try... > *>>* Cheers chris > *> > Chris, > I'll try your changes with that hunk removed. I don't see why it > shouldn't bootstrap with only that patch applied as the xgcc and final gcc > should now all look via xcrun for the SDK location. > Jack > > > > If I might ask for a little testing on all the systems we support before we > do that. > > Although I have been pushing the SDKROOT business for a while now, for all > recent systems, we have no idea yet how this might affect bootstrapping all > the older systems we support. > > I’d hate to have to go back and just put this all back in again :> > > > Ken > > Actually, removing the section breaks the bootstrap. What is currently unimplemented in the upstream changes is an additional fallback layer where, when SDKROOT is unset, the compiler would execute `xcrun --show-sdk-path` in order to set it. Apple's approach is to use compiler wrappers in /usr/bin which call the actual compilers via xcrun. Iain Sandoe has objected to that approach in the past as resulting in unwanted overhead in compiles, but I think if it were just the final fallback position of the compiler that wouldn't be much of a performance hit. Also, note that if you execute the buried clang compilers in /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin or /Library/Developer/CommandLineTools/usr/bin that they can't find the SDK. Jack