This is the mail archive of the
mailing list for the GCC project.
Re: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)
Jonathan Wakely <firstname.lastname@example.org> writes:
> On 19 May 2012 12:36, Gabriel Dos Reis wrote:
>> On Fri, May 18, 2012 at 10:53 PM, Jay K <email@example.com> 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>.