Jay K <jay.kr...@cornell.edu> writes: > I know gccgo is actually C++. > But why was no-rtti specified? Maybe that is for the other code, the C code?
Answered previously. > But I see: > > > and using -fno-rtti saves some space in the generated compiler. > > > > Is it worth it? Sure, why not? We make similar changes for much smaller benefits. It's worth bearing in mind that it is causing you trouble because 1) you are not using the recommend and tested build procedure, and 2) you are using the non-recommended procedure starting with a compiler that is 7 years old. You have perfectly good reasons for doing that, but the reality is that if you want to do this kind of thing, you have to be prepared for problems. > I guess you could configure with and without -fno-rtti + #include > <unordered_hashmap> and use > > the combination that works? Kind of you said that, but alternatively, use > unordered_hashmap either way, > > but only -fno-rtti if it works? I do realize though there is another factor, > it might be > > interesting to use just map, for older compilers/libraries, since unordered > is "new". You don't need to try it either way, because if <tr1/unordered_map> is unavailable the Go frontend will simply use <ext/hash_map>. And if <ext/hash_map> is unavailable, the Go frontend will use <map>. In other words, the Go frontend is already prepared to fall back, based on the results of configure tests. The problem here is that the configure test sees that <tr1/unordered_map> is available, but does not realize that although the header is available it does not actually work when using -fno-rtti. Ian
