jlevy@arisia.Xerox.COM (Jacob Levy) (12/01/88)
Environment: Sun 3/260 with SunOS 3.5. I have gcc 1.31 compiled without problem (including stage1 and stage2), and retrieved g++ 1.27. Then, I followed the instructions in g++/README, except for making symbolic links to configure the system (after the whole-sale symbolic linking phase). Instead, I ran the shell script gcc.config with 'sun3' which set up things for me. I also had the MAX_SETS_PER_INSN problem. This constant is not mentioned anywhere else in g++ or gcc-1.31. I simply defined it to be 16, inside an #ifndef MAX_SETS_PER_INSN. I know this is probably incorrect, but, what the heck.. The second problem was with loop.c, where the flag_strength_reduce variable is used. It turns out that this is defined in gcc-1.31/flags.h but not in g++/flags.h. Replacing the link between flags.h and g++/flags.h with a link to gcc-1.31/flags.h fixed this problem. The third problem was in init.c. Around line 1866 there's an #ifdef SOS which gets strange parsing errors, and likewise for the #ifdef starting around line 1940. Bracketing those with #ifdef NOTDEF solved those problems. Heck, talk about brute force lobotomy.. Function stash_inline_prefix in method.c was declared both extern and static. gcc complains... Function build_up_reference in convert.c was declared both extern and static. gcc complains... Finally, upon loading c++, a list of undefined references is printed as follows: _check_newline _finput _init_lex _lineno ___eprintf _token_buffer _reinit_parse_for_function _check_for_missing_semicolon _yylex _make_reference_declarator _make_pointer_declarator _combine_strings _reinit_parse_for_method _ridpointers _do_pending_inlines _operator_name_string _build_operator_fnname _set_float_handler _emit_note_force _gen_extend_insn _flag_strength_reduce _error_for_asm _current_function_returns_struct Finnaly, to add insult to injury, gcc dies with a fatal error 11 in this loading phase.. --Jacob
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (12/01/88)
jlevy@arisia.Xerox.COM (Jacob Levy) writes:
I have gcc 1.31 compiled without problem (including stage1 and
stage2), and retrieved g++ 1.27.
Stop right there. That is your problem. For any instantiation of G++
x.y, you must install it with GCC x.y, not GCC x.y+epsilon.
--Karlexodus@mfgfoc.uucp (Greg Onufer) (12/02/88)
From article <KARL.88Dec1094817@triceratops.cis.ohio-state.edu>, by karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste): > Stop right there. That is your problem. For any instantiation of G++ > x.y, you must install it with GCC x.y, not GCC x.y+epsilon. This is a little misleading.... If you have g++ x.y, then you must use the SOURCES of the back-end of gcc x.y when creating the links between your gcc source directory and your g++ source directory. You can, however, compile it with any version of gcc that you prefer... I used gcc-1.28 to compile g++-1.27/gcc-1.27... it works fine. I'll probably re-compile it with gcc-1.31 to see if it does any better in speed.... -greg -- Greg Onufer // Focus Semiconductor // University of the Pacific exodus@cheers.uucp (daver!cheers!exodus@Sun.COM) 415-965-0604