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