[Bug target/87243] FSF needs to use xcrun on darwin18 to find system headers in SDK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243 --- Comment #4 from Iain Sandoe --- 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!.
[Bug target/87243] FSF needs to use xcrun on darwin18 to find system headers in SDK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Iain Sandoe from comment #1) > I am strongly against making GCC's configure depend on xcrun. It is quite > possible that GCC could be used, for example, with PureDarwin - or on > systems without any Xcode install (using headers built from the OpenSource > packages). > > So, yes we have to find a solution to finding the headers, > but no, (at least I don't agree) that trying into yet another tool we don't > control is that solution. It could be conditional on system version. As long as there's a fallback path for cases where there's no xcrun, it should be okay. See for example what the emacs configure does: http://git.savannah.gnu.org/cgit/emacs.git/tree/configure.ac#n73
[Bug target/87243] FSF needs to use xcrun on darwin18 to find system headers in SDK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243 --- Comment #2 from Jack Howarth --- (In reply to Iain Sandoe from comment #1) > I am strongly against making GCC's configure depend on xcrun. It is quite > possible that GCC could be used, for example, with PureDarwin - or on > systems without any Xcode install (using headers built from the OpenSource > packages). > > So, yes we have to find a solution to finding the headers, > but no, (at least I don't agree) that trying into yet another tool we don't > control is that solution. The problem is finding a mechanism which doesn't use Apple's xcrun yet still allows you to find the SDK since the location of Xcode.app can change with renaming and hence the location of the SDK.
[Bug target/87243] FSF needs to use xcrun on darwin18 to find system headers in SDK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243 --- Comment #1 from Iain Sandoe --- I am strongly against making GCC's configure depend on xcrun. It is quite possible that GCC could be used, for example, with PureDarwin - or on systems without any Xcode install (using headers built from the OpenSource packages). So, yes we have to find a solution to finding the headers, but no, (at least I don't agree) that trying into yet another tool we don't control is that solution.
