[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4

[matthew.thompson at nasa dot gov]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330

--- Comment #22 from Matt Thompson <matthew.thompson at nasa dot gov> ---
(In reply to Iain Sandoe from comment #19)
> (In reply to Matt Thompson from comment #17)
> 
> > > b) (remind me) what is the "--with-native-system-header-dir=/usr/include"
> > > meant to provide?  It seems like you are maybe mixing cross-configuration
> > > options with native ones...
> > 
> > This was my attempt to try to work around the fact that Apple no longer
> > supplies a /usr/include:
> > 
> > https://developer.apple.com/documentation/xcode_release_notes/
> > xcode_10_release_notes#3035624
> > 
> > Now, I'm not sure that gcc itself needs /usr/include, but many of the
> > libraries and more I compile with gcc seem to assume it. And I've gotten to
> > the point where I just couldn't figure out how to pass '-isysroot' down to
> > code like f2py (gcc is called by f2py but f2py only passes down Fortran
> > flags. And I just *cannot* get our CMake system to pass
> > CFLAGS='-isysroot...' to the gcc call within f2py).
> > 
> > So, I thought I'd look around and saw that Homebrew built a little
> > differently:
> > 
> > https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc.rb
> > 
> > adding:
> >       elsif MacOS.version >= :mojave
> >         # System headers are no longer located in /usr/include
> >         args << "--with-native-system-header-dir=/usr/include"
> >         args <<
> > "--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
> 
> I don't know what they intended to achieve with this.  There *is* one
> gremlin with the sysroot being
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk which is that
> /usr/local/include is still a usable directory and needs to be searched
> *without* prepending the sysroot.  This is something I want to fix during
> the next couple of months - but isn't necessary *unless* you've installed
> packages into /usr/local that you want to use.
> 
> (A workaround is to add -I... so it shouldn't be a show-stopper)

Luckily (?) for me, there is nothing in my /usr/local/include save for Fuse
headers. Since I can't install Homebrew in its default /usr/local (I do it in
user space), it's pretty dang pure on my system!


> 
> 
> > My hope was perhaps this would "embed" in gcc the fact that sysroot is not
> > in /usr/include but was in
> > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include and so f2py
> > would work again.
> > 
> > Is it just the --with-sysroot that I'd need to "hardcode" a gcc with that
> > sysroot?
> 
> the --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
> should "just work" (modulo the gotcha about /usr/local mentioned) with no
> need for any additional magic.

Ooh. Okay. I'll give that a shot.

> 
> > I have tried the same configure line with gcc 8.2.0 loaded, but I get:
> > 
> > checking whether we are cross compiling... configure: error: in
> > `/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD-820loaded':
> > configure: error: cannot run C compiled programs.
> > If you meant to cross compile, use `--host'.
> > See `config.log' for more details
> 
> If you want to use GCC as the bootstrap and it was built for a system with
> /usr/include [and now that directory has been removed] then you need to
> supply it with a sysroot explicitly as I do.
> 
> CC="gcc-8-x --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
> CXX="g++-8.x --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
> (on the configure line)

Hmm. Okay. I'll give this a shot. I suppose I want to use clang just because
I'll have to keep bootstrapping with a previous version forever, right? 

And is this done at the configure stage? Make stage? My autotools-fu is a bit
weak.

> 
> 
> > Note, looking at Homebrew again, I do see they also build with:
> > 
> >   make BOOT_LDFLAGS=-Wl,-headerpad_max_install_names
> 
> That is solving a different problem - where it would seem that they intend
> to use install_name_tool to update the install paths and are allowing the
> maximum space.
> 
> > would that help?
> 
> very unlikely.

Huh. This might actually be something that we've hit in CMake on other codes,
but if it's not needed, I won't do it for now.