On Mon, May 21, 2012 at 12:08 AM, Ian Lance Taylor <i...@google.com> wrote: > Gabriel Dos Reis <g...@integrable-solutions.net> writes: > >> On Sun, May 20, 2012 at 10:30 PM, Ian Lance Taylor <i...@google.com> wrote: >> >>> To be clear, as far as I can see the Go frontend isn't doing anything >>> wrong or dubious. It just happens to #include <tr1/unordered_map> when >>> it is available but <unordered_map> is not. It looks like in gcc 4.0 >>> you can not #include <tr1/unordered_map> when using -fno-rtti. >>> >>> We could work around this by changing gcc/configure.ac to check whether >>> that #include <tr1/unordered_map> works with -fno-rtti. If that fails, >>> the Go frontend will next try <ext/hash_map>. >> >> Is it unacceptable for the Go front-end to use the stage1 g++, especially >> as we are moving toward switching to C++? > > The Go frontend does use the stage1 g++. > > I assume that this error can only occur when using --disable-bootstrap > or when building Go in stage 1. I don't see how this error could occur > when building stages 2 or 3 of a bootstrap.
OK. In that case, maybe make Go build only in stage2. The reason I am suggesting this is that will save you from all the vaguaries of partial support of anything after C++03. I suspect that could be made to work even with --disable-bootstrap, or am I off? -- Gaby
