> --enable-stage1-languages=go. (Mail to the OP is bouncing for me, by
> the way.)
I don't know why.
I'm getting them, at least via the list.
> Since the OP is apparently seeing Go build in stage 1, I assume that the
> OP is configuring with --disable-bootstrap or with
Right. I thought I was clear on that.
So I guess there is nothing to see here..move along..but..why the use of
-fno-rtti?
It seems like a guess of "more work for less good"?
i.e. remove those lines in configure and more fairly reasonable stuff works?
I can see maybe the opposite though.
Maybe the point is to avoid poor rtti implementations in old gcc bootstrap??
Or maybe the point was to compile C, really C code, with g++, and turn off
"gratituitous"
C++ features that the code "doesn't even come near" (i.e. the bulk of gcc
really is C
that is compatible with gcc, vs. the go frontend that is currently a rare case
of "actual C++".
If that's the rationale, again, maybe the lines should just be removed. I
understand this is
much to do about very little.
Heck maybe rtti and exceptions are decent enough out there that stage1 could
use them??
I "always" use -disable-bootstrap.
So much gain for acceptable pain.
I know I'm cutting corners, but I'm in active development of very small changes.
My bootstrap compiler isn't super wierd/bad, just a somewhat old gcc/g++.
(I have relatively recently bootstrapped from K&R cc on HP-UX though gcc 3.x
to get to gcc 4.x, and buggy
compilers I think on Irix that slightly miscompile GNU make, forcing one to
loop back with
gcc and rebuild make and then rebuild gcc (maybe in-tree the first time, I
forget..I should check my notes..)..
But anyway...
I don't want to change a header and have make go through and build the compiler
multiple times.
I have enough problems with incrementality building way too much..that I should
look into..
I really just wanted to step through gccgo to understand its implementation to
inform my own front end work.
(Yes, go is certainly an interesting hybrid -- native code + static compilation
+ static typing + C-like syntax + garbage collection + fast compilation
via a good module system instead of the C preprocessor toiling over the same
million lines repeatedly... -- you don't see that often. :)
Thank you,
- Jay
----------------------------------------
> From: i...@google.com
> To: g...@integrable-solutions.net
> CC: jwakely....@gmail.com; jay.kr...@cornell.edu; gcc@gcc.gnu.org
> Subject: Re: -fno-rtti in configure.ac breaks building go? (older g++,
> -disable-bootstrap)
> Date: Sun, 20 May 2012 22:41:08 -0700
>
> 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
