https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #14 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Jeremy Huddleston Sequoia from comment #12)
> > (In reply to Francois-Xavier Coudert from comment #11)
> > > (In reply to Jeremy Huddleston Sequoia from comment #10)
> > > > Given those, gcc only builds if we have the DevSDK ("headers at /"
> > > > package)
> > > > installed.
> > >
> > > I may be misunderstanding what you say: GCC builds and runs fine without
> > > the
> > > headers in /usr/include. At Homebrew, we are not recommending users to
> > > install the /usr/include headers package, and we build and run GCC fine.
> > > The
> > > configuration is the following
> > > (https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc.rb):
> > >
> > > --with-native-system-header-dir=/usr/include
> > > --with-sysroot=/path/to/sdk
> > >
> > > if the system headers are in /path/to/sdk/usr/include. Thus, on a Mojave
> > > installation with Xcode CLT installed, we set /path/to/sdk to
> > > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
> >
> > Yeah, I documented the workaround of using --with-sysroot in the MacPorts
> > port when filing these bugs and passed on to Homebrew, but that ends up
> > causing gcc's search path to always look in that sysroot (ie, it becomes the
> > default sysroot). Thus, users will build executables that behave
> > differently based on where there SDK was located on their build system.
> > That is certainly not what is desired. If you have a build fleet that used
> > an SDK that was located at /Volumes/SDKs/AllMacSDKs/MacOSX10.14.sdk at build
> > time, but your users have
> > /Applications/MyXcodesPath/Xcode-10.app/.../MacOSX.sdk, then that mismatch
> > can cause problems.
> >
> > The point of --with-sysroot is to change the behavior of the built product
> > (the final gcc executable).
>
> Right - this is pretty much the comment I made in 87243; --with-sysroot=
> sets the default, which might not be the one implied by an xcode-select
> executed later.
>
> Of course, one *can* pass --sysroot=`xcrun blah blah` on any command line
> (for the built compiler) as a work-around.
>
> I was trying to work on a scheme where the possible SDK search paths were
> provided by symlinks [in the user's home dir], with some configure-time
> specified search order (including the option to search /). Initial
> population of the symlinks might be time-significant - but subsequent
> following should be less than a process switch. There was some email
> exchange on this between me, Eric and Mike .. I will try to find it in my
> archives.
You found it yet?
>
> IMO we really don't want to go down the road where we launch another
> executable for every sub-process invocation on the toolchain that needs to
> know the SDK path!
>
> > The point of --with-build-sysroot is to change
> > how we build gcc.
>
> Indeed --with-build-sysroot has some nasties - I did some work on it for
> darwin when trying to get to a situation where we can configure for
> "x86_64-apple-darwin" without that implying 10.0 ;)
>
> Need to fish that out too.
