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

[iains at gcc dot gnu.org]

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

--- Comment #23 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Matt Thompson from comment #22)
> (In reply to Iain Sandoe from comment #19)
> > (In reply to Matt Thompson from comment #17)
> 
> > > 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? 

I use GCC (most of the time) because (in general) I'm bootstrapping all
languages including Ada (which needs an Ada compiler to bootstrap).  IFF you're
interest is c,c++,fortran then you can use clang or GCC as the bootstrap.

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

see: https://gcc.gnu.org/ml/gcc-testresults/2019-08/msg00608.html 

as a "general" case of configuration with different sysroots for the built and
bootstrap compilers. a breakdown of the configure line with some notes below 

.../configure --prefix=/where/you/want/it

 --target=x86_64-apple-darwin18
 --host=x86_64-apple-darwin18
 --build=x86_64-apple-darwin18
^^^ you can drop these and it will figure out the version

 --with-sysroot=/opt/iains/SDKs/darwin18-2 
^^^^ this is the sysroot that will be built into the compiler and used
automatically when it's invoked (in this case, the one from XC10.2 tools) you
would put /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk here.

 --with-ld=/opt/iains/x86_64-apple-darwin/xtools-2-2-3/bin/ld 
--with-as=/opt/iains/x86_64-apple-darwin/xtools-2-2-3/bin/llas

^^^ you can ignore these, I have separate builds of ld64 and an assembler with
some non-compiler bug fixes

 --with-cpu=corei7 
--disable-nls 
--with-iconv-prefix=/usr
^^^ you can ignore these too

--enable-languages=all
^^^ likewise
--enable-version-specific-runtime-libs
^^^ I prefer to use this, since it ensures that libraries are installed into
version-specific paths and thus should never clash on a rebuild/update of the
compiler.

 CC='gcc --sysroot=/opt/iains/SDKs/darwin18'
 CXX='g++ --sysroot=/opt/iains/SDKs/darwin18'

^^^ these are invoking a GCC-8.3 that's placed first in my PATH, but using an
older SDK that doesn't have the "zippered" TBD files (since the ld64 on that
GCC-8 doesn't grok those).



> > > 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.

Perhaps, but it should not affect the compiler bootstrap or install - the paths
for the built libraries are set to their install versions at build time - so
they should be "long enough".