please can you do "grep CFI" gccc/auto-host.h and put the output here?

(In reply to Iain Sandoe from comment #1)
> please can you do "grep CFI" gccc/auto-host.h and put the output here?

also what version of Xcode you're using and/or what version of GCC you are using to bootstrap.  I built and installed all languages for the 9.1rc2 version - so unless there was a patch after than but before the release, this is a surprising fail..

For the grep:

[(544) 01:48 PM] $ grep CFI gcc/auto-host.h
/* Define 0/1 if your assembler supports CFI directives. */
#define HAVE_GAS_CFI_DIRECTIVE 0
#define HAVE_GAS_CFI_PERSONALITY_DIRECTIVE 1
#define HAVE_GAS_CFI_SECTIONS_DIRECTIVE 1

As for the other question, I didn't have any of my modules loaded so, I guess it used the mac "gcc" aka clang:

[(545) 01:48 PM] $ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[(546) 01:48 PM] $ /usr/bin/xcodebuild -version
Xcode 10.2.1
Build version 10E1001

Also: I do have all the log files still, so if you'd like anything grep'ed in there, let me know.

(In reply to Matt Thompson from comment #4)
> Also: I do have all the log files still, so if you'd like anything grep'ed
> in there, let me know.

not at this time.. I am trying to figure out what is different about our configurations.

---

can you confirm that this was a clean build (including that the target install directory was deleted before the build?)

(In reply to Iain Sandoe from comment #5)
> (In reply to Matt Thompson from comment #4)
> > Also: I do have all the log files still, so if you'd like anything grep'ed
> > in there, let me know.
> 
> not at this time.. I am trying to figure out what is different about our
> configurations.
> 
> ---
> 
> can you confirm that this was a clean build (including that the target
> install directory was deleted before the build?)

It was a clean build. I always build out-of-source so it was a new directory and I'd never installed GCC 9.1.0 before, so the install directory was new as well.

Let me try building again in a new directory with a new install location. Of course, being the impressive GCC build, it might be Monday before I can report back (it's a work laptop that stays at work).

(In reply to Matt Thompson from comment #6)
> (In reply to Iain Sandoe from comment #5)
> > (In reply to Matt Thompson from comment #4)
> > > Also: I do have all the log files still, so if you'd like anything grep'ed
> > > in there, let me know.
> > 
> > not at this time.. I am trying to figure out what is different about our
> > configurations.
> > 
> > ---
> > 
> > can you confirm that this was a clean build (including that the target
> > install directory was deleted before the build?)
> 
> It was a clean build. I always build out-of-source so it was a new directory
> and I'd never installed GCC 9.1.0 before, so the install directory was new
> as well.
> 
> Let me try building again in a new directory with a new install location. Of
> course, being the impressive GCC build, it might be Monday before I can
> report back (it's a work laptop that stays at work).

OK thanks, as it happens I won't be able to try on Darwin18 before next Weds, so no hurry.

(In reply to Iain Sandoe from comment #7)
> (In reply to Matt Thompson from comment #6)
> > (In reply to Iain Sandoe from comment #5)
> > > (In reply to Matt Thompson from comment #4)
> > > > Also: I do have all the log files still, so if you'd like anything grep'ed
> > > > in there, let me know.
> > > 
> > > not at this time.. I am trying to figure out what is different about our
> > > configurations.
> > > 
> > > ---
> > > 
> > > can you confirm that this was a clean build (including that the target
> > > install directory was deleted before the build?)
> > 
> > It was a clean build. I always build out-of-source so it was a new directory
> > and I'd never installed GCC 9.1.0 before, so the install directory was new
> > as well.
> > 
> > Let me try building again in a new directory with a new install location. Of
> > course, being the impressive GCC build, it might be Monday before I can
> > report back (it's a work laptop that stays at work).
> 
> OK thanks, as it happens I won't be able to try on Darwin18 before next
> Weds, so no hurry.

I just tried to rebuild gcc 9.1.0 on my laptop, and I got the same error at the same point in make install.

I'll try a few other experiments (remove /usr/local/bin from my path in case brew is causing an issue, though it didn't before).

Or should I be using one of my other compilers to build gcc? I have built gcc 8.2.0. Instead of using clang, I could try that...though I'm not sure how. Just pass in CC and CXX to configure?

(In reply to Matt Thompson from comment #8)
> (In reply to Iain Sandoe from comment #7)
> > (In reply to Matt Thompson from comment #6)
> > > (In reply to Iain Sandoe from comment #5)
> > > > (In reply to Matt Thompson from comment #4)
> > > > > Also: I do have all the log files still, so if you'd like anything grep'ed
> > > > > in there, let me know.
> > > > 
> > > > not at this time.. I am trying to figure out what is different about our
> > > > configurations.
> > > > 
> > > > ---
> > > > 
> > > > can you confirm that this was a clean build (including that the target
> > > > install directory was deleted before the build?)
> > > 
> > > It was a clean build. I always build out-of-source so it was a new directory
> > > and I'd never installed GCC 9.1.0 before, so the install directory was new
> > > as well.
> > > 
> > > Let me try building again in a new directory with a new install location. Of
> > > course, being the impressive GCC build, it might be Monday before I can
> > > report back (it's a work laptop that stays at work).
> > 
> > OK thanks, as it happens I won't be able to try on Darwin18 before next
> > Weds, so no hurry.
> 
> I just tried to rebuild gcc 9.1.0 on my laptop, and I got the same error at
> the same point in make install.

One possible (although I suspect unlikely) issue is a race condition when instslling symlinks which is known to occur on AFPS (the system I use for testing is HHFS+).

does it reliably still fail if you try to restart the install?

> I'll try a few other experiments (remove /usr/local/bin from my path in case
> brew is causing an issue, though it didn't before).

OK - when I build toolchains the environment has no macports/fink/homebrew content so there's no possibility of interaction.
>

> Or should I be using one of my other compilers to build gcc? 

I have built with both clang (10.2 command line tools) and a toolchain based on GCC 8.3 (although not a formal release) - both builds succeeded - I have no access to my Darwin18 system right now, so not able to attempt to repeat your exercise.

Presumably, the 8.2 toolchains is correctly installed and has not been moved, so that the shared libraries from that are on the correct paths (the kind of error you are seeing could be the wrong dylib being found).

If you can find the exact command line that fails and repeat it, prepended by DYLD_PRINT_LIBRARIES=1, that will show you which dylibs are loaded as the command tries to execute (there might be quite a lot of output, so not necessarily easy to interpret)

I have built
> gcc 8.2.0. Instead of using clang, I could try that...though I'm not sure
> how. Just pass in CC and CXX to configure?

yes, and/or make sure that the GCC toolchain bin dir is before the system ones in your path.

(In reply to Iain Sandoe from comment #9)
> (In reply to Matt Thompson from comment #8)
> > 
> > I just tried to rebuild gcc 9.1.0 on my laptop, and I got the same error at
> > the same point in make install.
> 
> One possible (although I suspect unlikely) issue is a race condition when
> instslling symlinks which is known to occur on AFPS (the system I use for
> testing is HHFS+).
> 
> does it reliably still fail if you try to restart the install?

It does indeed. Very repeatable. 

> 
> > I'll try a few other experiments (remove /usr/local/bin from my path in case
> > brew is causing an issue, though it didn't before).
> 
> OK - when I build toolchains the environment has no macports/fink/homebrew
> content so there's no possibility of interaction.

I don't usually remove it from my path because it had never caused any issues before. Note that I specifically do not let brew install gcc (or MPI). I like that control. I'm currently running a "no /usr/local/bin" test so we shall see if it helps.

(I will say, as an aside, that I also can never get *spack* to build GCC on my laptop. Any version. Never figured that out either which is weird because it is a build from source!)

> >
> 
> > Or should I be using one of my other compilers to build gcc? 
> 
> I have built with both clang (10.2 command line tools) and a toolchain based
> on GCC 8.3 (although not a formal release) - both builds succeeded - I have
> no access to my Darwin18 system right now, so not able to attempt to repeat
> your exercise.
> 
> Presumably, the 8.2 toolchains is correctly installed and has not been
> moved, so that the shared libraries from that are on the correct paths (the
> kind of error you are seeing could be the wrong dylib being found).

I install every release to its own tree and control access through lmod, so I can test this pretty easily. When I start up, I just have basics on my system (though I do symlink some brew utils to my ~/bin like gsed->sed because I cannot handle BSD sed. Grah!)

> 
> If you can find the exact command line that fails and repeat it, prepended
> by DYLD_PRINT_LIBRARIES=1, that will show you which dylibs are loaded as the
> command tries to execute (there might be quite a lot of output, so not
> necessarily easy to interpret)

I just tried this and nothing happens. I tried both "DYLD_PRINT_LIBRARIES=1 g++ ..." and "env DYLD_PRINT_LIBRARIES=1 g++ ..." No change in output.

> 
> I have built
> > gcc 8.2.0. Instead of using clang, I could try that...though I'm not sure
> > how. Just pass in CC and CXX to configure?
> 
> yes, and/or make sure that the GCC toolchain bin dir is before the system
> ones in your path.

I'll try this as well as soon as I can (I can maybe manage make -j4 on this laptop, so builds aren't quick!). Do I need to pass FC as well? Or does the gcc build with fortran not care?

(In reply to Matt Thompson from comment #10)
> (In reply to Iain Sandoe from comment #9)
> > (In reply to Matt Thompson from comment #8)


> I don't usually remove it from my path because it had never caused any
> issues before. Note that I specifically do not let brew install gcc (or
> MPI). I like that control. I'm currently running a "no /usr/local/bin" test
> so we shall see if it helps.

OK - let's be clear here. You must install GCC into the path that its configured with in order for the correct shared libraries to be found at runtime.

so, if yo configure --prefix=/foo/bar/baz and then intstall into /baz/bar/foo that will not work correctly.

The error you are showing seems that you are not finding the same libstdc++ at runtime as was assumed to be available by the build.

> > If you can find the exact command line that fails and repeat it, prepended
> > by DYLD_PRINT_LIBRARIES=1, that will show you which dylibs are loaded as the
> > command tries to execute (there might be quite a lot of output, so not
> > necessarily easy to interpret)
> 
> I just tried this and nothing happens. I tried both "DYLD_PRINT_LIBRARIES=1
> g++ ..." and "env DYLD_PRINT_LIBRARIES=1 g++ ..." No change in output.

"which g++" probably says you are using clang++ and that it a protected exe that will elide DYLD_* when invoked. In that case, it's hard to do that test.
> 
> > 
> > I have built
> > > gcc 8.2.0. Instead of using clang, I could try that...though I'm not sure
> > > how. Just pass in CC and CXX to configure?
> > 
> > yes, and/or make sure that the GCC toolchain bin dir is before the system
> > ones in your path.
> 
> I'll try this as well as soon as I can (I can maybe manage make -j4 on this
> laptop, so builds aren't quick!). Do I need to pass FC as well? Or does the
> gcc build with fortran not care?

Fortran is built with the C++ compiler, but I'd put the GCC bin dir in the path first - and then you will be able to do the DYLD_** commands using the bootstrap compiler tools to install.

(In reply to Iain Sandoe from comment #11)
> (In reply to Matt Thompson from comment #10)
> > (In reply to Iain Sandoe from comment #9)
> > > (In reply to Matt Thompson from comment #8)
> 
> 
> > I don't usually remove it from my path because it had never caused any
> > issues before. Note that I specifically do not let brew install gcc (or
> > MPI). I like that control. I'm currently running a "no /usr/local/bin" test
> > so we shall see if it helps.
> 
> OK - let's be clear here. You must install GCC into the path that its
> configured with in order for the correct shared libraries to be found at
> runtime.
> 
> so, if yo configure --prefix=/foo/bar/baz and then intstall into
> /baz/bar/foo that will not work correctly.
> 
> The error you are showing seems that you are not finding the same libstdc++
> at runtime as was assumed to be available by the build.

Oh. I only ever do "make install" if I get --prefix wrong, I rebuild the whole thing.

> 
> > > If you can find the exact command line that fails and repeat it, prepended
> > > by DYLD_PRINT_LIBRARIES=1, that will show you which dylibs are loaded as the
> > > command tries to execute (there might be quite a lot of output, so not
> > > necessarily easy to interpret)
> > 
> > I just tried this and nothing happens. I tried both "DYLD_PRINT_LIBRARIES=1
> > g++ ..." and "env DYLD_PRINT_LIBRARIES=1 g++ ..." No change in output.
> 
> "which g++" probably says you are using clang++ and that it a protected exe
> that will elide DYLD_* when invoked. In that case, it's hard to do that test.
> > 

Yeah.

> > > 
> > > I have built
> > > > gcc 8.2.0. Instead of using clang, I could try that...though I'm not sure
> > > > how. Just pass in CC and CXX to configure?
> > > 
> > > yes, and/or make sure that the GCC toolchain bin dir is before the system
> > > ones in your path.
> > 
> > I'll try this as well as soon as I can (I can maybe manage make -j4 on this
> > laptop, so builds aren't quick!). Do I need to pass FC as well? Or does the
> > gcc build with fortran not care?
> 
> Fortran is built with the C++ compiler, but I'd put the GCC bin dir in the
> path first - and then you will be able to do the DYLD_** commands using the
> bootstrap compiler tools to install.

Well, 9.1.0 built just fine with 8.2.0 loaded in my environment. This seems to point to clang, which, well, doesn't surprise me as clang and I have had a difficult life together, but then again clang built 5.4.0 up to 8.2.0 just fine for me. 

I'm ran a 'make check' and got:

Fixed:  time.h
Fixed:  tinfo.h
Fixed:  types/vxTypesBase.h
Fixed:  unistd.h
Newly fixed header:  sys/ucred.h

There were fixinclude test FAILURES
make[2]: *** [Makefile:177: check] Error 1
make[2]: Leaving directory '/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD-820loaded/fixincludes'
make[1]: *** [Makefile:3829: check-fixincludes] Error 2
make[1]: Leaving directory '/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD-820loaded'
make: *** [Makefile:2358: do-check] Error 2

So...huh. Not sure what to do there. Still, fortune favors the bold/naive and I'll continue work with this 9.1.0 and try to build my MPI stack, etc. and see how it handles our model.

(In reply to Matt Thompson from comment #12)
> (In reply to Iain Sandoe from comment #11)
> > (In reply to Matt Thompson from comment #10)
> > > (In reply to Iain Sandoe from comment #9)
> > > > (In reply to Matt Thompson from comment #8)

> > > > yes, and/or make sure that the GCC toolchain bin dir is before the system
> > > > ones in your path.
> > > 
> > > I'll try this as well as soon as I can (I can maybe manage make -j4 on this
> > > laptop, so builds aren't quick!). Do I need to pass FC as well? Or does the
> > > gcc build with fortran not care?
> > 
> > Fortran is built with the C++ compiler, but I'd put the GCC bin dir in the
> > path first - and then you will be able to do the DYLD_** commands using the
> > bootstrap compiler tools to install.
> 
> Well, 9.1.0 built just fine with 8.2.0 loaded in my environment. This seems
> to point to clang, which, well, doesn't surprise me as clang and I have had
> a difficult life together, but then again clang built 5.4.0 up to 8.2.0 just
> fine for me. 
> 
> I'm ran a 'make check' and got:
> 
> Fixed:  time.h
> Fixed:  tinfo.h
> Fixed:  types/vxTypesBase.h
> Fixed:  unistd.h
> Newly fixed header:  sys/ucred.h
> 
> There were fixinclude test FAILURES
> make[2]: *** [Makefile:177: check] Error 1
> make[2]: Leaving directory
> '/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD-820loaded/fixincludes'
> make[1]: *** [Makefile:3829: check-fixincludes] Error 2
> make[1]: Leaving directory
> '/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD-820loaded'
> make: *** [Makefile:2358: do-check] Error 2

do you have runtest and/or autopen in your path - if not then you won't get any results - you probably need to append the path(s) for home-brew to the end of your PATH.
> 
> So...huh. Not sure what to do there. Still, fortune favors the bold/naive
> and I'll continue work with this 9.1.0 and try to build my MPI stack, etc.
> and see how it handles our model.

OK, so I am happy to work with you to get this working for your environment.  GCC should build and install with clang as the bootstrap compiler.

For that, I think maybe we should just pick up a direct email discussion and close this PR (since it seems something specific to your setup).

NOTE: toolchain "vendors" (including macports et. al.) would normally not support anything that they don't test so the advice would be either:

a) build in macports/fink/homebrew unchanged or
b) configure and build stand-alone with full control over the environment.

Personally, I do (b) because I want the toolchain to work independent of any dependencies from the distributions.  Many people who are just building a toolchain for their own use can do (a).

(In reply to Iain Sandoe from comment #13)
> (In reply to Matt Thompson from comment #12)
> > (In reply to Iain Sandoe from comment #11)
> > > (In reply to Matt Thompson from comment #10)
> > > > (In reply to Iain Sandoe from comment #9)
> > > > > (In reply to Matt Thompson from comment #8)
> 

> > Well, 9.1.0 built just fine with 8.2.0 loaded in my environment. This seems
> > to point to clang, which, well, doesn't surprise me as clang and I have had
> > a difficult life together, but then again clang built 5.4.0 up to 8.2.0 just
> > fine for me. 
> > 
> > I'm ran a 'make check' and got:
> > 
> > Fixed:  time.h
> > Fixed:  tinfo.h
> > Fixed:  types/vxTypesBase.h
> > Fixed:  unistd.h
> > Newly fixed header:  sys/ucred.h
> > 
> > There were fixinclude test FAILURES
> > make[2]: *** [Makefile:177: check] Error 1
> > make[2]: Leaving directory
> > '/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD-820loaded/fixincludes'
> > make[1]: *** [Makefile:3829: check-fixincludes] Error 2
> > make[1]: Leaving directory
> > '/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD-820loaded'
> > make: *** [Makefile:2358: do-check] Error 2

This was 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90379

fixed on trunk and for 9.2 (so current snapshots from the branch should have the fix).

Other than that, I can't reproduce the problem locally - it installs for me whether built using the XC10.2 command line tools, or my own (GCC-8.3) toolset.

... is there anything more we need to do on this PR?
(very happy to help, but not sure how to make pogress without a reproducer for the issue).

Iain,

I seem to still have issues. I downloaded 9.2.0 this morning and built it with:

$ ../gcc-9.2.0/configure --prefix=/Users/mathomp4/installed/Core/gcc-gfortran/9.2.0 --enable-languages=c,c++,fortran --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk |& tee configure.log
$ make -j4 |& tee make.log
$ make install |& tee makeinstall.log

Note I'm using a slightly different configure step as I'm trying to emulate what Homebrew does with its code as I no longer have /usr/include due to an Xcode update (and since I know Apple won't allow it soon, I'm trying to learn to work around that).

But, eventually, the build fails with the *exact same error*:

g++ -std=gnu++98    -g -O2 -DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H  -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-fold.o c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o i386-c.o darwin-c.o \
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv  ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./isl/.libs  -lisl -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./gmp/.libs -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./mpfr/src/.libs -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./mpc/src/.libs -lmpc -lmpfr -lgmp   -L./../zlib -lz
ld: warning: could not create compact unwind for __ZL18ix86_target_stringxxiiPKcS0_11fpmath_unitbb.cold: stack size is large but stack subq instruction not found
ld: warning: could not create compact unwind for __ZNK9vec_usage4dumpEP12mem_locationR9mem_usage: stack subq instruction is too different from dwarf stack size
ld: warning: could not create compact unwind for __ZL18cselib_record_setsP8rtx_insn.cold: stack size is large but stack subq instruction not found
ld: warning: could not create compact unwind for __ZL16may_eliminate_ivP11ivopts_dataP6iv_useP7iv_candPP9tree_nodeP9tree_code: stack subq instruction is too different from dwarf stack size
ld: warning: could not create compact unwind for __ZL16may_eliminate_ivP11ivopts_dataP6iv_useP7iv_candPP9tree_nodeP9tree_code.cold: stack size is large but stack subq instruction not found
ld: warning: could not create compact unwind for __Z12find_reloadsP8rtx_insniiiPs: stack subq instruction is too different from dwarf stack size
ld: warning: could not create compact unwind for __Z12find_reloadsP8rtx_insniiiPs.cold: stack size is large but stack subq instruction not found
ld: warning: could not create compact unwind for __ZN12_GLOBAL__N_113pass_backprop7executeEP8function.cold: stack size is large but stack subq instruction not found
ld: warning: could not create compact unwind for __ZL13powi_as_multsP20gimple_stmt_iteratorjP9tree_nodex: stack subq instruction is too different from dwarf stack size
ld: warning: could not create compact unwind for __Z11inline_callP11cgraph_edgebP3vecIS0_7va_heap6vl_ptrEPibPb.cold: stack size is large but stack subq instruction not found
ld: warning: could not create compact unwind for __ZL20process_alt_operandsi.cold: stack size is large but stack subq instruction not found
Undefined symbols for architecture x86_64:
  "std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)", referenced from:
      ipa_icf::sem_item_optimizer::worklist_push(ipa_icf::congruence_class*) in libbackend.a(ipa-icf.o)
      ipa_icf::sem_item_optimizer::traverse_congruence_split(ipa_icf::congruence_class* const&, bitmap_head* const&, ipa_icf::traverse_split_pair*) in libbackend.a(ipa-icf.o)
      ipa_icf::sem_item_optimizer::subdivide_classes_by_sensitive_refs() in libbackend.a(ipa-icf.o)
      ipa_icf::sem_item_optimizer::process_cong_reduction() in libbackend.a(ipa-icf.o)
  "std::__detail::_List_node_base::_M_unhook()", referenced from:
      ipa_icf::sem_item_optimizer::worklist_pop() in libbackend.a(ipa-icf.o)
  "std::_Rb_tree_decrement(std::_Rb_tree_node_base*)", referenced from:
      std::pair<std::_Rb_tree_iterator<basic_block_def*>, bool> std::_Rb_tree<basic_block_def*, basic_block_def*, std::_Identity<basic_block_def*>, std::less<basic_block_def*>, std::allocator<basic_block_def*> >::_M_insert_unique<basic_block_def* const&>(basic_block_def* const&&&) in libbackend.a(auto-profile.o)
      std::pair<std::_Rb_tree_iterator<gimple*>, bool> std::_Rb_tree<gimple*, gimple*, std::_Identity<gimple*>, std::less<gimple*>, std::allocator<gimple*> >::_M_insert_unique<gimple*>(gimple*&&) in libbackend.a(auto-profile.o)
      std::_Rb_tree<char const*, std::pair<char const* const, unsigned int>, std::_Select1st<std::pair<char const* const, unsigned int> >, autofdo::string_compare, std::allocator<std::pair<char const* const, unsigned int> > >::_M_get_insert_unique_pos(char const* const&) in libbackend.a(auto-profile.o)
      std::_Rb_tree<char const*, std::pair<char const* const, unsigned int>, std::_Select1st<std::pair<char const* const, unsigned int> >, autofdo::string_compare, std::allocator<std::pair<char const* const, unsigned int> > >::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator<std::pair<char const* const, unsigned int> >, char const* const&) in libbackend.a(auto-profile.o)
      std::_Rb_tree<unsigned int, std::pair<unsigned int const, long long>, std::_Select1st<std::pair<unsigned int const, long long> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, long long> > >::_M_get_insert_unique_pos(unsigned int const&) in libbackend.a(auto-profile.o)
      std::_Rb_tree<unsigned int, std::pair<unsigned int const, long long>, std::_Select1st<std::pair<unsigned int const, long long> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, long long> > >::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator<std::pair<unsigned int const, long long> >, unsigned int const&) in libbackend.a(auto-profile.o)
      std::_Rb_tree<unsigned int, std::pair<unsigned int const, autofdo::count_info>, std::_Select1st<std::pair<unsigned int const, autofdo::count_info> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, autofdo::count_info> > >::_M_get_insert_unique_pos(unsigned int const&) in libbackend.a(auto-profile.o)
      ...
  "std::_Rb_tree_increment(std::_Rb_tree_node_base const*)", referenced from:
      autofdo::afdo_indirect_call(gimple_stmt_iterator*, std::map<unsigned int, long long, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, long long> > > const&, bool) in libbackend.a(auto-profile.o)
      autofdo::function_instance::total_annotated_count() const in libbackend.a(auto-profile.o)
      autofdo::autofdo_source_profile::~autofdo_source_profile() in libbackend.a(auto-profile.o)
      autofdo::function_instance::find_icall_target_map(gcall*, std::map<unsigned int, long long, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, long long> > >*) const in libbackend.a(auto-profile.o)
      autofdo::autofdo_source_profile::update_inlined_ind_target(gcall*, autofdo::count_info*) in libbackend.a(auto-profile.o)
  "std::_Rb_tree_increment(std::_Rb_tree_node_base*)", referenced from:
      autofdo::function_instance::~function_instance() in libbackend.a(auto-profile.o)
      std::_Rb_tree<char const*, std::pair<char const* const, unsigned int>, std::_Select1st<std::pair<char const* const, unsigned int> >, autofdo::string_compare, std::allocator<std::pair<char const* const, unsigned int> > >::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator<std::pair<char const* const, unsigned int> >, char const* const&) in libbackend.a(auto-profile.o)
      std::_Rb_tree<unsigned int, std::pair<unsigned int const, long long>, std::_Select1st<std::pair<unsigned int const, long long> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, long long> > >::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator<std::pair<unsigned int const, long long> >, unsigned int const&) in libbackend.a(auto-profile.o)
      std::_Rb_tree<unsigned int, std::pair<unsigned int const, autofdo::count_info>, std::_Select1st<std::pair<unsigned int const, autofdo::count_info> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, autofdo::count_info> > >::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator<std::pair<unsigned int const, autofdo::count_info> >, unsigned int const&) in libbackend.a(auto-profile.o)
      std::_Rb_tree<std::pair<unsigned int, unsigned int>, std::pair<std::pair<unsigned int, unsigned int> const, autofdo::function_instance*>, std::_Select1st<std::pair<std::pair<unsigned int, unsigned int> const, autofdo::function_instance*> >, std::less<std::pair<unsigned int, unsigned int> >, std::allocator<std::pair<std::pair<unsigned int, unsigned int> const, autofdo::function_instance*> > >::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator<std::pair<std::pair<unsigned int, unsigned int> const, autofdo::function_instance*> >, std::pair<unsigned int, unsigned int> const&) in libbackend.a(auto-profile.o)
      std::_Rb_tree<unsigned int, std::pair<unsigned int const, autofdo::function_instance*>, std::_Select1st<std::pair<unsigned int const, autofdo::function_instance*> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, autofdo::function_instance*> > >::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator<std::pair<unsigned int const, autofdo::function_instance*> >, unsigned int const&) in libbackend.a(auto-profile.o)
      ivs_params_clear(std::map<isl_id*, tree_node*, std::less<isl_id*>, std::allocator<std::pair<isl_id* const, tree_node*> > >&) in libbackend.a(graphite-isl-ast-to-gimple.o)
      ...
  "std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)", referenced from:
      std::pair<std::_Rb_tree_iterator<basic_block_def*>, bool> std::_Rb_tree<basic_block_def*, basic_block_def*, std::_Identity<basic_block_def*>, std::less<basic_block_def*>, std::allocator<basic_block_def*> >::_M_insert_unique<basic_block_def* const&>(basic_block_def* const&&&) in libbackend.a(auto-profile.o)
      std::pair<std::_Rb_tree_iterator<gimple*>, bool> std::_Rb_tree<gimple*, gimple*, std::_Identity<gimple*>, std::less<gimple*>, std::allocator<gimple*> >::_M_insert_unique<gimple*>(gimple*&&) in libbackend.a(auto-profile.o)
      std::_Rb_tree<unsigned int, std::pair<unsigned int const, long long>, std::_Select1st<std::pair<unsigned int const, long long> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, long long> > >::_M_insert_node(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node<std::pair<unsigned int const, long long> >*) in libbackend.a(auto-profile.o)
      autofdo::string_table::read() (.part.0) in libbackend.a(auto-profile.o)
      std::_Rb_tree_iterator<std::pair<unsigned int const, autofdo::count_info> > std::_Rb_tree<unsigned int, std::pair<unsigned int const, autofdo::count_info>, std::_Select1st<std::pair<unsigned int const, autofdo::count_info> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, autofdo::count_info> > >::_M_emplace_hint_unique<std::piecewise_construct_t const&, std::tuple<unsigned int const&>, std::tuple<> >(std::_Rb_tree_const_iterator<std::pair<unsigned int const, autofdo::count_info> >, std::piecewise_construct_t const&&&, std::tuple<unsigned int const&>&&, std::tuple<>&&) in libbackend.a(auto-profile.o)
      autofdo::function_instance::read_function_instance(auto_vec<autofdo::function_instance*, 0ul>*, long long) in libbackend.a(auto-profile.o)
      autofdo::autofdo_source_profile::read() in libbackend.a(auto-profile.o)
      ...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [../../gcc-9.2.0/gcc/c/Make-lang.in:85: cc1] Error 1
make[2]: Leaving directory '/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/gcc'
make[1]: *** [Makefile:5084: install-gcc] Error 2
make[1]: Leaving directory '/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD'
make: *** [Makefile:2409: install] Error 2

I was hoping 9.2.0 would fix this. :(

Hi Matt,

(In reply to Matt Thompson from comment #15)

> I seem to still have issues. I downloaded 9.2.0 this morning and built it
> with:
> 
> $ ../gcc-9.2.0/configure
> --prefix=/Users/mathomp4/installed/Core/gcc-gfortran/9.2.0
> --enable-languages=c,c++,fortran --disable-multilib
> --with-native-system-header-dir=/usr/include
> --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk |& tee
> configure.log
> $ make -j4 |& tee make.log
> $ make install |& tee makeinstall.log

a) --disable-multilib should no longer be needed [that PR was fixed on 9.2]

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

> I was hoping 9.2.0 would fix this. :(

I am very happy to try and help you fix this - and to patch trunk / 9.3 if there's a bug - but right now the builds I've done (both with GCC as bootstrap - for Ada and with clang as bootstrap) have succeeded on Darwin9..Darwin18.

Iain,

The (In reply to Iain Sandoe from comment #16)
> Hi Matt,
> 
> (In reply to Matt Thompson from comment #15)
> 
> > I seem to still have issues. I downloaded 9.2.0 this morning and built it
> > with:
> > 
> > $ ../gcc-9.2.0/configure
> > --prefix=/Users/mathomp4/installed/Core/gcc-gfortran/9.2.0
> > --enable-languages=c,c++,fortran --disable-multilib
> > --with-native-system-header-dir=/usr/include
> > --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk |& tee
> > configure.log
> > $ make -j4 |& tee make.log
> > $ make install |& tee makeinstall.log
> 
> a) --disable-multilib should no longer be needed [that PR was fixed on 9.2]

Okay. I'll remove that.

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

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?

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

So that's not right.

Now, that said, I can run that same link step that fails with clang g++ and *explicitly* use g++-8.2.0 and it seems to work:

/Users/mathomp4/installed/Core/gcc-gfortran/8.2.0/bin/g++ -std=gnu++98    -g -O2 -DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H  -o cc1plus \
      cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/class.o cp/constexpr.o cp/constraint.o cp/cp-gimplify.o cp/cp-objcp-common.o cp/cp-ubsan.o cp/cvt.o cp/cxx-pretty-print.o cp/decl.o cp/decl2.o cp/dump.o cp/error.o cp/except.o cp/expr.o cp/friend.o cp/init.o cp/lambda.o cp/lex.o cp/logic.o cp/mangle.o cp/method.o cp/name-lookup.o cp/optimize.o cp/parser.o cp/pt.o cp/ptree.o cp/repo.o cp/rtti.o cp/search.o cp/semantics.o cp/tree.o cp/typeck.o cp/typeck2.o cp/vtable-class-hierarchy.o attribs.o incpath.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o i386-c.o darwin-c.o cc1plus-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv  ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./isl/.libs  -lisl -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./gmp/.libs -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./mpfr/src/.libs -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./mpc/src/.libs -lmpc -lmpfr -lgmp   -L./../zlib -lz

After that if i unload the gcc 8.2.0 module, the make install succeeds.

Note, looking at Homebrew again, I do see they also build with:

  make BOOT_LDFLAGS=-Wl,-headerpad_max_install_names

would that help?

> 
> > I was hoping 9.2.0 would fix this. :(
> 
> I am very happy to try and help you fix this - and to patch trunk / 9.3 if
> there's a bug - but right now the builds I've done (both with GCC as
> bootstrap - for Ada and with clang as bootstrap) have succeeded on
> Darwin9..Darwin18.

FWIW: this was my clang-bootstrapped test of the release candidate:

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

 --prefix=/opt/iains/x86_64-apple-darwin18/gcc-9-wip
 --with-sysroot=/opt/iains/SDKs/darwin18-2 
--enable-languages=all CC='clang --sysroot=/opt/iains/SDKs/darwin18' CXX='clang++ --sysroot=/opt/iains/SDKs/darwin18'

NOTE: if you have the command line tools installed you do not need to specify CC and CXX.  The "--with-sysroot=/opt/iains/SDKs/darwin18-2 " is pointing to exactly the same SDK you have.

i.e. I would expect 

--prefix=/somewhere/you/want/it 
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

to be completely sufficient.

(will review your comments in a moment)

(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)


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

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


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

(In reply to Iain Sandoe from comment #19)
> (In reply to Matt Thompson from comment #17)
> 

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

Packages that assume /usr/include should "just work" with the sysrooted compiler without any extra magic (I build LLVM and its associated things with GCC and a sysroot all the time).  cmake can take a CMAKE_OSX_SYSROOT=/path/to/sysroot if you need to be explicit.

otherwise, I'd expect it to honour CMAKE_CFLAGS= and CMAKE_CXXFLAGS= (but...)

(In reply to Iain Sandoe from comment #20)
> (In reply to Iain Sandoe from comment #19)
> > (In reply to Matt Thompson from comment #17)
> > 
> 
> > > 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).
> 
> Packages that assume /usr/include should "just work" with the sysrooted
> compiler without any extra magic (I build LLVM and its associated things
> with GCC and a sysroot all the time).  cmake can take a
> CMAKE_OSX_SYSROOT=/path/to/sysroot if you need to be explicit.
> 
> otherwise, I'd expect it to honour CMAKE_CFLAGS= and CMAKE_CXXFLAGS= (but...)

Iain,

Oh, no, CMake is smart. It's f2py that isn't smart. It doesn't really understand its own environment. CMake is smart and sees it's on Darwin and does CMAKE_OSX_SYSROOT so it uses it in all the C code it compiles. The problem is f2py deep in its own code base is calling $CC and it is too removed from the CMake system. Running CFLAGS='-isysroot...' f2py does work, but CMake is munging the freaking call so it gets things like:

CFLAGS='\-isysroot \'/Library...' 

and I'm not enough of a CMake guru to fix it. Luckily, my boss (who is) will be back from travel soon.

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

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

(In reply to Iain Sandoe from comment #23)
>  --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.

Iain,

Thanks for the explanations. I'm trying a new build now with gcc-8.2.0 as the compiler passed to configure. 

Here's a(nother dumb) question: let's assume everything works. How exactly can one see what the sysroot is on a compiler? I.e., I could run "gcc-8.2.0 -xyz" and see it looks for /usr/include, but "gcc-9.2.0 -xyz" would show the /Library/Developer...

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

Huh. I'll keep this in mind. I'm not adding it yet, but I'll put it in my notes for this compiler build.

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

Oh, yes. I was thinking of things we'll be building with this new GCC. I just wish I could figure out the build-with-clang issue. It's like it's missing some C++ library in its link line:

c-family/c-spellcheck.o i386-c.o darwin-c.o \
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv  ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./isl/.libs  -lisl -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./gmp/.libs -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./mpfr/src/.libs -L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./mpc/src/.libs -lmpc -lmpfr -lgmp   -L./../zlib -lz
l

Now, I do think it's a bit odd that 'main.o' is *after* 'libbackend.a' as I usually put all my .o first then my .a when I build, but I think that's just stylistic. And there's the usual autotools business of libraries repeating (libcommon, libcpp). 

Plus the C++ is so dense I don't know what this is looking for:

std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)", referenced from:
      ipa_icf::sem_item_optimizer::worklist_push(ipa_icf::congruence_class*) in libbackend.a(ipa-icf.o)

And my usual suggestion of "just add -lstd++ or lc++" when I see C++ link issues probably isn't right when you might be building those libraries! :)

(In reply to Matt Thompson from comment #24)
> (In reply to Iain Sandoe from comment #23)
> >  --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.

> Thanks for the explanations. I'm trying a new build now with gcc-8.2.0 as
> the compiler passed to configure. 
> 
> Here's a(nother dumb) question: let's assume everything works. How exactly
> can one see what the sysroot is on a compiler? I.e., I could run "gcc-8.2.0
> -xyz" and see it looks for /usr/include, but "gcc-9.2.0 -xyz" would show the
> /Library/Developer...

gcc --print-sysroot

gcc --help will show you the things that the driver can print for you and point to other help lines that might be useful.

> > --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.
> 
> Huh. I'll keep this in mind. I'm not adding it yet, but I'll put it in my
> notes for this compiler build.

right, it should not affect your result.
> 
> > 
> >  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".
> 
> Oh, yes. I was thinking of things we'll be building with this new GCC. I
> just wish I could figure out the build-with-clang issue. It's like it's
> missing some C++ library in its link line:

build with clang should (does for me) work :)

> Now, I do think it's a bit odd that 'main.o' is *after* 'libbackend.a' as I
> usually put all my .o first then my .a when I build, but I think that's just
> stylistic. 

Actually, one difference from the "usual linker" rules on Darwin is that ld64 will repeatedly re-visit presented libraries (in their presented order) to satisfy symbols.  There is no need for the dance of repeating .a files several times.


> Plus the C++ is so dense I don't know what this is looking for:
> 
> std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)",
> referenced from:
>       ipa_icf::sem_item_optimizer::worklist_push(ipa_icf::congruence_class*)
> in libbackend.a(ipa-icf.o)

TBH, neither do I from that snippet - but I do think that a correctly installed command line tools should just succeed with.

configure --prefix=/somewhere/nice --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

and use clang as the bootstrap compiler.

[as an aside, I do wonder where you are getting your GMP, MPFR, MPC and (optionally) ISL from ?] - for the record I usually build them in-tree and thus they are bootstrapped with the compiler.

(In reply to Iain Sandoe from comment #25)
> 
> > Thanks for the explanations. I'm trying a new build now with gcc-8.2.0 as
> > the compiler passed to configure. 
> > 
> > Here's a(nother dumb) question: let's assume everything works. How exactly
> > can one see what the sysroot is on a compiler? I.e., I could run "gcc-8.2.0
> > -xyz" and see it looks for /usr/include, but "gcc-9.2.0 -xyz" would show the
> > /Library/Developer...
> 
> gcc --print-sysroot
> 
> gcc --help will show you the things that the driver can print for you and
> point to other help lines that might be useful.

Ah. Should have figure that out myself. :shame:

> > 
> > Oh, yes. I was thinking of things we'll be building with this new GCC. I
> > just wish I could figure out the build-with-clang issue. It's like it's
> > missing some C++ library in its link line:
> 
> build with clang should (does for me) work :)

Lucky you. :) My laptop and gcc have some sort of shining thing going on. I can't build gcc with Spack either. 

> 
> > Now, I do think it's a bit odd that 'main.o' is *after* 'libbackend.a' as I
> > usually put all my .o first then my .a when I build, but I think that's just
> > stylistic. 
> 
> Actually, one difference from the "usual linker" rules on Darwin is that
> ld64 will repeatedly re-visit presented libraries (in their presented order)
> to satisfy symbols.  There is no need for the dance of repeating .a files
> several times.

Huh. Good to know!

> 
> 
> > Plus the C++ is so dense I don't know what this is looking for:
> > 
> > std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)",
> > referenced from:
> >       ipa_icf::sem_item_optimizer::worklist_push(ipa_icf::congruence_class*)
> > in libbackend.a(ipa-icf.o)
> 
> TBH, neither do I from that snippet - but I do think that a correctly
> installed command line tools should just succeed with.
> 
> configure --prefix=/somewhere/nice
> --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
> 
> and use clang as the bootstrap compiler.
> 
> [as an aside, I do wonder where you are getting your GMP, MPFR, MPC and
> (optionally) ISL from ?] - for the record I usually build them in-tree and
> thus they are bootstrapped with the compiler.

I get those guys by running:

  ./contrib/download_prerequisites

when I first get the source. Maybe there's a better way? I think a recipe I found long ago did that, so I've just done the same thing myself as it seemed to work.

(In reply to Matt Thompson from comment #26)
> (In reply to Iain Sandoe from comment #25)
> > 

> > > Oh, yes. I was thinking of things we'll be building with this new GCC. I
> > > just wish I could figure out the build-with-clang issue. It's like it's
> > > missing some C++ library in its link line:
> > 
> > build with clang should (does for me) work :)
> 
> Lucky you. :) My laptop and gcc have some sort of shining thing going on. I
> can't build gcc with Spack either.

I will (later) repeat the exercise and paste exactly what I did - the Darwin18 machine is busy building / testing 9.2 bootstrapped with GCC....

.. checking for malformed PATH or things lurking in hash might spring to mind in the presence of such spooks...

> > [as an aside, I do wonder where you are getting your GMP, MPFR, MPC and
> > (optionally) ISL from ?] - for the record I usually build them in-tree and
> > thus they are bootstrapped with the compiler.
> 
> I get those guys by running:
> 
>   ./contrib/download_prerequisites
> 
> when I first get the source. Maybe there's a better way? I think a recipe I
> found long ago did that, so I've just done the same thing myself as it
> seemed to work.

That's fine - essentially, you're building them from source and therefore don't need to worry about --with-gmp= configure options etc.

For the record, I'm using GMP-6.1.2, MPFR-3.1.6, MPC-1.1.0 and ISL-0.20.

(In reply to Iain Sandoe from comment #27)
> That's fine - essentially, you're building them from source and therefore
> don't need to worry about --with-gmp= configure options etc.
> 
> For the record, I'm using GMP-6.1.2, MPFR-3.1.6, MPC-1.1.0 and ISL-0.20.

Well, it looks like download_prerequisites might be behind the times:

gmp='gmp-6.1.0.tar.bz2'
mpfr='mpfr-3.1.4.tar.bz2'
mpc='mpc-1.0.3.tar.gz'
isl='isl-0.18.tar.bz2'

I'm going to try and download the newest versions of all these and build with them. Maybe that'll help (though I don't see much/any C++ in them...).

Also, this did seem to build GCC:

CC="/Users/mathomp4/installed/Core/gcc-gfortran/8.2.0/bin/gcc --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" CXX="/Users/mathomp4/installed/Core/gcc-gfortran/8.2.0/bin/g++ --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" ../gcc-9.2.0/configure --prefix=/Users/mathomp4/installed/Core/gcc-gfortran/9.2.0-820loaded --enable-languages=c,c++,fortran --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk |& tee configure.log

So if nothing else, I have a way around the clang issue. I'll inform you on the updated prerequisites build.

(In reply to Matt Thompson from comment #28)
> (In reply to Iain Sandoe from comment #27)
> > That's fine - essentially, you're building them from source and therefore
> > don't need to worry about --with-gmp= configure options etc.
> > 
> > For the record, I'm using GMP-6.1.2, MPFR-3.1.6, MPC-1.1.0 and ISL-0.20.
> 
> Well, it looks like download_prerequisites might be behind the times:
> 
> gmp='gmp-6.1.0.tar.bz2'
> mpfr='mpfr-3.1.4.tar.bz2'
> mpc='mpc-1.0.3.tar.gz'
> isl='isl-0.18.tar.bz2'
> 
> I'm going to try and download the newest versions of all these and build
> with them. Maybe that'll help (though I don't see much/any C++ in them...).

Yeah. Didn't help. Still, it was a fun exercise.

If GCC was on github, I'd make a pull request to update the download_prerequisites script, though. Unless there's a good reason to use these version?

(In reply to Matt Thompson from comment #30)
> (In reply to Matt Thompson from comment #28)
> > (In reply to Iain Sandoe from comment #27)
> > > That's fine - essentially, you're building them from source and therefore
> > > don't need to worry about --with-gmp= configure options etc.
> > > 
> > > For the record, I'm using GMP-6.1.2, MPFR-3.1.6, MPC-1.1.0 and ISL-0.20.
> > 
> > Well, it looks like download_prerequisites might be behind the times:
> > 
> > gmp='gmp-6.1.0.tar.bz2'
> > mpfr='mpfr-3.1.4.tar.bz2'
> > mpc='mpc-1.0.3.tar.gz'
> > isl='isl-0.18.tar.bz2'
> > 
> > I'm going to try and download the newest versions of all these and build
> > with them. Maybe that'll help (though I don't see much/any C++ in them...).
> 
> Yeah. Didn't help. Still, it was a fun exercise.

That was a long shot to solve your problem; was mainly documenting what I've done that worked.

> If GCC was on github, I'd make a pull request to update the
> download_prerequisites script, though. Unless there's a good reason to use
> these version?

AFAIK, the pre-reqs are the minimum versions and there's nothing to sop one from deciding to use newer (keeping the minimum to the lowest practical is advantageous in compatibility).  Updating any GCC dependency has wide ramifications - many folks might just use the version installed on their system (if it's Linux) - on Darwin we care somewhat less, since we have to build them anyway.

====

I've started a 9.2 build/install/test cycle with xcode10.2 toolchain as the bootstrap - will post the results here later/tomorrow.

Well it still Works For Me™
If this is still not working for you, I might speculate that something is corrupted in an install somewhere, perhaps reinstall command line tools / Xcode?

$ /src-local/gcc-9-branch/configure --prefix=/opt/iains/x86_64-apple-darwin18/gcc-9-2c --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk CC='clang --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk' CXX='clang++ --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk' >conf.txt 
configure: WARNING: using in-tree isl, disabling version check
*** This configuration is not supported in the following subdirectories:
     target-libvtv target-libphobos target-libgo gnattools gotools target-libada target-libhsail-rt target-zlib target-libffi target-liboffloadmic
    (Any other directories should still work fine.)

$ time nice make -j4 >b.txt 2>e.txt && time make install >ins.txt 2>ine.txt && time nice make -j3 -k check >cc.txt 2>ec.txt

real	116m21.832s
user	298m14.583s
sys	37m13.525s

real	0m28.414s
user	0m11.306s
sys	0m11.122s

real	209m50.700s
user	359m34.820s
sys	170m38.173s

$ clang --version
Apple LLVM version 10.0.1 (clang-1001.0.46.3)

$ uname -v
Darwin Kernel Version 18.7.0: Thu Jun 20 18:42:21 PDT 2019; root:xnu-4903.270.47~4/RELEASE_X86_64

$ /opt/iains/x86_64-apple-darwin18/gcc-9-2c/bin/gcc --version
gcc (GCC) 9.2.0

Have we now resolved this issue?

All current open branches work OK for me on all Darwin versions from 10.4 - 11.2.

Please update if there is still something to fix.

Iain,

Apologies. I forgot about this. Seeing as I'm now using GNU 10.2.0 on my Macbook...I guess it's working.

I currently do:

../gcc-10.2.0/configure --prefix=$HOME/installed/Core/gcc-gfortran/10.2.0 --enable-languages=c,c++,fortran --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk |& tee configure.log

when I configure it which is much as you suggested.

My guess is I worked with my admins nuking and restoring XCode until we got it right (or something, government laptops are fun, no sudo, lots of restrictions...).

Thanks for your help, and I can't wait for 10.3 or 11.0 or whatever is next! N

Note: I'm still on an Intel Mac, so I won't need to bother "Iain Sandoe, master of M1 GNU" about that for a while. :D

(In reply to Matt Thompson from comment #34)

> Apologies. I forgot about this. Seeing as I'm now using GNU 10.2.0 on my
> Macbook...I guess it's working.

great!

> and I can't wait for 10.3 or 11.0 or whatever is next!

10.3 release candidates should start in a few days, and then GCC-11 will be not too long after that ...

> Note: I'm still on an Intel Mac, so I won't need to bother "Iain Sandoe,
> master of M1 GNU" about that for a while. :D

heh, M1 support in GCC12 is my objective - but there's a lot of work to do to get it there, let's see if 'experimental' can be morphed into 'production'.