🚀 go-pugleaf

I built libg++-2.2 on the Convex running Convex OS 9.0 and using
gcc-2.2.2.  To summarize quickly, I had some problems about the
preprocessor definitions of fpos_t and _G_fpost_t, the use of G_ARGS,
a problem caused by fixinclude's removal of an ssize_t typedef,
inhibition of ranlib running in Makefiles, and use of dtoa.  Below I
describe my problems and workarounds.  I think some of this may
involve bugs in libg++ and hope that this information will help
future versions work better on the convex.

Don Bashford
bashford@scripps.edu
(for October, email automatically forwarded to me in Dortmund, Germany)

-------------------------------------------------------

Fixincludes has been run prior to the libg++ build.
Libg++ was configured using,

./configure convex-c2 --prefix=/work/bashford/gnu

and built using GNU-make with simple commands, "make all", "make check", etc.
unless otherwise indicated.

A parse error occurs during the compilation of String.cc in 
/usr/include/stdio.h on the lines:

    typedef struct {
      int __offset[2];
    } fpos_t;
 
because fpos_t is #defined in to _G_fpos_t in streambuf.h and _G_fpos_t
is #defined as long in _G_config.h.

There are a couple of problems involved.  First, gen-params is supposed
to assign a definition for _G_fpos_t consistent with the system's own,
but it cannot grock multi-line typdefs like the convex's, so it uses
its default which is "long".  copying /usr/include/stdio.h into the
gcc include tree and editing the above typdef to a single line,
it is possible to get a consistent define in _G_config but syntax
errors again occur during the compilation of String.cc in stdio.h
because definitions now expand to something like

    typdef struc { .. } struct { .. } 

If I try to #undef fpos_t at the end of streambuf.h (which is the only
file in libg++ the redefines fpos_t) String.cc will compile but
parsestream.C fails to compile first because parsestream.h counts on
the fpos_t redefine, and second because parsestream.h has an
assignment of an integer constant to pos_at_line_start, a varaible of type
fpos_t, which is not legal for a struct.

The workaround I found is to edit stdio.h to typdef fpos_t as "long long"
since sizeof int is 2 and sizeof long long is 4 on the convex.
This works in spite of the fact that #defines in stdio now expand
to produce "typedef long long long long".  Why this works is a mystery
to me.

The next problem is that the use of _G_ARGS in g++-include/signal.h
and wait.h cause problems like:

./../g++-include/signal.h:47: conflicting types for `int  kill (...)' 
./../g++-include/signal.h:47: An argument type that has a default promotion 
./../g++-include/signal.h:47: can't match an empty parameter name list declaration. 
/usr/include/signal.h:141: previous declaration of `int  kill (short int, int)' 
and attempting to work around by using _G_USE_PROTOS causes other problems.
So edit g++-include's signal.h and wait.h not to
use the _G_ARGS macro for kill and waitpid, respectively.

Compilation of sbufvform.C fails due to ssize_t not defined in
/usr/include/unistd.h.  I Traced the problem to the fact that
fixincludes places a an #ifndef _GCC_SIZET_T around the ssize_t typdef
in sys/types.h So I undid this "fix".

At first dtoa.C fails to compile because after preprocessing a line,
"Exactly one of IEEE_8087, IEEE_MC68k, VAX, or IBM should be defined"
is present.  I can get it to compile by commenting out this line, but
this leads to failure of floating point I/O in the tFile test.  My
workaround is to inhibit use of dtoa.C by commenting out the
USE_DTOA define in ioprivate.h

Linking during the build and install fails because libraries are not
ranlibbed.  I traced this to the fact that configure put the line,
"RANLIB=true" in the Makefiles which inhibits running ranlib.
My workaround is to put "RANLIB=ranlib" on the make command line,
but I suppose there is a configure flag to accomplish this too.

With these workarounds, libg++ compiles, installs and passes all its
tests, except that tCurses locks up xterm windows.  I have not investiged
curses problems further as I don't write such programs.