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)
Gabriel Dos Reis <firstname.lastname@example.org> writes:
> On Mon, May 21, 2012 at 12:08 AM, Ian Lance Taylor <email@example.com> wrote:
>> Gabriel Dos Reis <firstname.lastname@example.org> writes:
>>> On Sun, May 20, 2012 at 10:30 PM, Ian Lance Taylor <email@example.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
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