Gabriel Dos Reis <g...@integrable-solutions.net> writes: > 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.
By default, Go will only build in stages 2 and 3. Since the OP is apparently seeing Go build in stage 1, I assume that the OP is configuring with --disable-bootstrap or with --enable-stage1-languages=go. (Mail to the OP is bouncing for me, by the way.) That is, normally, everything should be fine. But if you use unusual configure options you can definitely get into unusual cases. Ideally those cases should be made to work if possible. It's not very important, though. Ian
