https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834
--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to John Marshall from comment #9) > The Homebrew folks have been configuring with a sysroot to work around this > on Mojave since it came out last year: > > --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk > > and it bootstraps fine (in the context of their recipe [1]). Nobody seems to > complain that frameworks etc in / are now missing, but it's entirely likely > that none of their users are exercising it hard enough to notice. Likewise, I configure this way pretty much all the time. The frameworks themselves (executable binaries) are not missing from / What's "missing" are the Header directories that used to be installed into / (pre Sierra command line tools). So now the Header directors, and a set of "tbd" files (representing the linkable objects) are presented in the SDK. - this is fine, as noted the paths they specify are correct for the runtimes. > This has an unfortunate side-effect that the compiler looks in the > non-existent /Library/.../MacOSX.sdk/usr/local/include instead of > /usr/local/include [2]. That's an irritation, indeed. > Longterm it seems like the GCC driver would need some basic xcrun > capabilities, but as an immediate fix for that it seems like a configure > option (--with-local-prefix-outside-sysroot? > --without-local-prefix-sysroot?) to make LOCAL_INCLUDE_DIR ignore sysroots > would be appropriate. (I've been composing such a proposal for gcc@...) Configuring without a sysroot isn't going to work - there are no headers in / to be found. What is possible is to configure with a "build-time" sysroot, and then to discover the actual one at runtime - the penalty there being potential 10ms+ time in looking something up (a bunch of syscalls at least). As I've noted before - it doesn't seem much until you multiply it by 400k for the GCC test suite... It's possible we could work around the /usr/include/local thing relatively easily, one can add un-sysrooted paths (and also compiler-relative paths). Making our own sysroot (which would allow us to control where it's installed) is next to impossible, since many of the Frameworks are closed source. > (I'm just a brewed-GCC user who'd like the compiler to basically work; not a > Homebrew maintainer.) We want it to work "out of the tin" - without external deps on a distro - so "fixing" it is in the plan. However configuring "--with-sysoot=" isn't actually broken, but a perfectly valid approach, and we can probably make some auto-discovery in the configure script that will work behind the scenes for most people.
