https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-09-21
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=87243
Ever confirmed|0 |1
--- Comment #13 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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.
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.
