Jonathan Wakely <jwakely....@gmail.com> writes: > On 19 May 2012 12:36, Gabriel Dos Reis wrote: >> On Fri, May 18, 2012 at 10:53 PM, Jay K <jay.kr...@cornell.edu> wrote: >>> >>> /src/gcc-4.7.0/configure -disable-bootstrap -enable-languages=go >>> >>> >>> book2:gccgo-4.7 jay$ g++ -v >>> Using built-in specs. >>> Target: i686-apple-darwin9 >>> Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking >>> -enable-werror --prefix=/usr --mandir=/share/man >>> --enable-languages=c,objc,c++,obj-c++ >>> --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ >>> --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib >>> --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic >>> --host=i686-apple-darwin9 --target=i686-apple-darwin9 >>> Thread model: posix >>> gcc version 4.0.1 (Apple Inc. build 5493) >>> >>> >>> a lot of: >>> >>> /usr/include/c++/4.0.0/tr1/functional_iterate.h:912: error: cannot use >>> typeid with -fno-rtti >>> /src/gcc-4.7.0/gcc/go/gofrontend/string-dump.h: At global scope: >> >> This is using TR1. So the question is whether the Go front-end is using >> it just as a convenience whether it really needs TR1 and the implied >> RTTI (typeid). > > In later releases tr1::function guards the code using RTTI with > __GXX_RTTI so it can be used with -no-rtti. > > I think the right answer is to use a later GCC or don't use > --disable-bootstrap.
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>. Ian
