https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #12 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org>
---
(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). The point of --with-build-sysroot is to change how we
build gcc.
