https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243
--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> --- All I'm asking is that that we describe the real bug (i.e. that we need to be able to find the headers when they are not installed in some Well Known Place). It should also work for -mmacosz-version-min != current system revision (and therefore, might need to deal with finding libraries too - or else, for example, we won't be able to build m32 exes). ----- As it happens, I had been giving this problem some thought - a couple of years ago. What we don't want is to cripple Darwin's toolchain by making it call more and more executables for each invocation. IFF you want to configure to use the current installed Xcode - you could just put --with-sysroot='xcrun --sdk ... etc` on the configure line. That doesn't solve the issue of the Xcode package being moved or the user issuing a --xcode-select ... ... so .... let's state the problem we want to solve and the cases we want to cover - and then figure out how to do it. The bug is not "we must use xcrun" the bug is "we need to find the headers under the following circumstances". I had in mind, for the record, some scheme using symlinks in the user's home directory (since using schemes writing into the /xxx dirs require elevated permissions). There's still a penalty in looking up through a link c.f. direct access to things - but it would me much less than running a second process and parsing the output. ==== JFTR: To support non-Apple-native clang builds I have to patch the LLVM cmake files to *avoid* the xcrun calls and use the SDk paths I want!.
