problems compiling gcc package on SunOS 4.1.4

[Robert Bonomi <bonomi at agresource dot com>]

This report is re: GCC v 3.0.1, as retrieved from prep.ai.mit.edu on
the evening of 19 Oct 2001.

Attempted build on SunOS 4.1.4.  have Sun's bundled 'cc', and gcc 2.95.3 


0) the README/INSTALL are excoriable, when it comes to what the components 
    of the package are, and how to compile/install a -single- component,
    or a selected subset.  a _simple_ list of the primary targets in the
    main Makefile would be *extremely* helpful. The makefiles have so much
    parameterization, etc. that it is *not* immediately obvious, even from
    reading the Makefile itself.

    related: it would be very useful to have one-line descriptions of what
    each first-level subdirectory is.  Would facilitate trimming the list
    of directories to process, when one doe _not_ want "everything, including
    the kitchen sink".


1) 'fastjar' fails to compile:

   a) uses (apparent) symbolic constant NULL, not defined anywhare
          workaround:  added appropriate #ifndef/#define/#endif

   b) uses strerror(), non-existant on SunOS 4.
          workaround: cobbled up a strerror _macro_, using sys_nerr and
                      sys_errlist[].

  comment: $diety only knows why just typing 'make' tries to build this
           *FIRST*, _before_ even building the new compiler!  you don't
           need _this_ to compile the compiler, right?

   status: beaten into submission. my patches not suitable for wider distrib.


2) can't compile g++.  *MULTIPLE* problems down in the subdirectories of
        'sparc-sun-sunOS4.1.4/libg++v3'

    a) 'signbit' in libmath bombs, with undefined names, because "BYTE_ORDER",
         in 'libmath/mathconf.h' is apparently not defined with a value that
         matches that of BIG_ENDIAN or LITTLE_ENDIAN -- mathconf.h *assumes*
         that value _IS_ one or the other.  Fails to emit _anything_ for the
         "ieee_double_shape_type".  

         Problem is either BYTE_ORDER is *mis-named*, or improperly (or not)
         initialized.  I'm not up to chasing down all the header dependencies,
         I saw BITS_BIG_ENDIAN, BYTES_BIG_ENDIAN, WORDS_BIG_ENDIAN, in the
         gcc/config/sparc/sparc.h file, and in similar other config files for
         other machines.  Suspect a possible naming problem.
            workaround: deconditionalized the case (big endian) that applied
                        to my hardware.

    b) compilation bombs, reference to "../gcc/{foo}", when the gcc directory
       is _two_ levels up.
            workaround: executed 'ln -s ../gcc gcc' in the sparc-sun-sunos4.1.4
              directory.
    c) make fails in 'gcc-3.0.1/sparc-sun-sunos4.1.4/libstdc++-v3/libsupc++',
       compiling 'eh_alloc.cc'.  multiple errors:
            "In file included from
      gcc-3.0.1/sparc-sun-sunos4.1.4/libstdc++-v3/include/cstdlib:31,
          from eh_alloc.cc:34:
      gcc-3.0.1/sparc-sun-sunos4.1.4/libstdc++-v3/include/bits/std_cstdlib.h:75:
         `div_t' not declared"

      also:
        line  76: 'ldiv_t' not declared
        line  86: 'div'    not declared
        line  91: 'ldiv'   not declared
        line  93: 'mblen'  not declared
        line 111: SYNTAX: "error before '(' token"

   status: "lions 2, christians 0".

     I have minimal C++ proficiency.  Tracking this back through the swamp
     is beyond me.  Fortunately, I don't particularly need C++ compilation 
     capabilities at this time.


A complete build takes a (seeming) eternity.  Over 40(!!) wall-clock hours
from solving the 'fastjar' problems till the 'libstdc' ones showed up. The
apparent culprit: numerous runs of 'configuration' scripts(?).  the checks
for specific functions seemed to be particularly slow.  literally minutes
would elapse between successive report lines. directly related thereunto: I
question the need for -seven- separate config.cache files, in seven different 
directories.

Between the 7 files, there are 1870+ lines, but only about 400 -unique- ones. 

I did see the -same- checks being run multiple times. I have to assume that
it was -not- simply displaying cached results when there is a lag, measured
in *minutes* (yes, _really_ -- halfway through the processing a configuration
session that started at 1:30 was still plodding along at 5:00!) between
successive items.