https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834
--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to r...@cebitec.uni-bielefeld.de from comment #5) > > --- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> --- > > I don't have 10.15 or xcode 11 yet .. > > No worry: I just happened to upgrade for reasons unrelated to gcc work > and gave it a whirl... > > > does ... > > configure --prefix ... > > --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk > > ..... > > Haven't tried that yet. I can once the current bootstrap (which is > still running) has completed. > > However, isn't --with-sysroot to completely override the system headers, > so any standard library in /usr/lib won't be found any longer? On some platforms, that might/would be the effect. However, on Darwin platforms the two-level namespace in libraries means that the recorded path at link time is found in the exe at runtime (and the SDKs contain the relevant paths for the runtimes to be found in /). AFAIK, there's no "global" ability to rebase the found libraries into a different tree at runtime (modulo the use of DYLD_LIBRARY_PATH, which is doubly inadvisable in the face of SIP and sandboxing of various dirs). So, when clang runs from xcrun, what is happening is that the --sysroot=/path/to/SDK is being added to each compile invocation. We could, of course, do that with GCC - it will work just fine - but that's a painful user experience. "--with-sysroot=/path/to/SDK" configuration has the effect of providing that path as a default. * It doesn't prevent one from supplying a --sysroot=/path/to/different/SDK on the compile line, but it saves you from _having_ to add the default. One way to look at this is that "/" is just a short SDK path, for systems <= Sierra that get headers/libs installed into / for an command line install. (this is one case in which the GCC driver can do a small part of what xcrun does - out of the tine - so long as the SDK doesn't move ... ) I'm reluctant to make the check at runtime, (e.g. if /usr/include is there, use '/' as the sysroot, otherwise use /Libary/....) it's easy to pile more and more stuff on but, 10ms here and there all adds up when one is running 400k tests. AFAICS - at present, GCC requires a fixed installation path - not because of the compiler, but because the runtimes have to be found somewhere known at compile time. The Apple-provided command lines tools/SDKs also install to a "Well Known Place" even if that is no longer '/' post Mojave - so the solution is reasonably portable. For someone (like me) who has no such installation, then it's assumed that they know (enough) about what they are doing to use a different invocation to configure to point to their SDK installation. I've been using this for several years now, rarely using '/' even on earlier systems...
