Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!psuvax1!psuvm!cunyvm!ndsuvm1!nu013809
From: NU013809@NDSUVM1.BITNET (Greg Wettstein)
Newsgroups: comp.unix.xenix.sco
Subject: Re: g++ on Xenix/386 (maybe)
Message-ID: <90328.084818NU013809@NDSUVM1.BITNET>
Date: 24 Nov 90 14:48:18 GMT
References: <3958@vela.acs.oakland.edu>
Organization: North Dakota Higher Education Computer Network
Lines: 61

I've had g++ 1.37.1 up and running for about a week on wind.  The only tests
that I have been able to conjure up for it are to compile the GNU g++ library
(1.37.0) and groff 0.6.  Both packages compiled without any seeming problems
but I have not been able to get the test cases for g++lib to run.  On the
other hand I got groff 0.6 off the ground yesterday and it seems to function
correctly, at least it seems to process all the man pages that I have
been collecting.

I am pretty sure that I can get the g++lib test cases running based upon my
experiences with getting groff operational.  The major problems that I ran into
in both cases was with the SCO include files.  I used the fix.h.xenix script
supplied with robobar's latest binary distribution of gcc, gas, gdb to patch
the SCO supplied include files and placed the corrected include files in
/usr/local/lib/gcc-include.  This works well for everything that is done with
gcc but problems arise when using g++.  The g++lib comes with include files
which are installed by in /usr/local/lib/g++-include.

The problems that I encountered were with the g++ include files using the
#include <//usr/include/..> convention.  g++ complained about conflicting
definitions for size_t in the /usr/include/time.h file.  After monkeying
around for longer than I cared to spend on the problem I just commented out
the typedef statements in the /usr/include files which were problematic.
Groff compiled without any difficulty and I am pretty sure that the test
cases for g++lib will probably function as they are supposed to.

The only other glitch that I encountered in bringing up groff was with a
conflicting function prototype for perror in /usr/include/errno.h.  Since
one of the gcc/g++ include files in /usr/local/lib allready defined it I
just commented out the problem line.  Groff seems to function very
pleasantly under Xenix 2.3.3.  I haven't had the opportunity to try and
print any documents generated using the -Tdvi option but I plan on trying
that this afternoon.  At any rate just having the ability to process man
pages on Xenix was well worth the effort.

One of the things I am thinking about doing is modifying the cccp.c module
to change the search heirarchy for include files.  This module is common
between g++ and gcc.  Since the fix.h.xenix script copies all the include
files from /usr/include I am thinking that just removing /usr/include from
the default search list in cccp.c might solve a lot of problems.  That
way the Microsoft compiler would have its own unadulterated include files
while gcc/g++ would have its own.  Of course this necessitates keeping two
copies of the include files around but in this day and age of large disk
drives it hardly seems a concern.  Especially when you consider that the
gc1plus executable measures in at +700000 bytes...

Hopefully other people on the net will find my experiences with g++ and
groff helpful.  If anyone has any comments or questions feel very free
to respond.  Please use the address in my sig. since mail gets to me faster
at the wind address.

                            As always,
                            Dr. G.W. Wettstein
                            Oncology Research Division Computing Facility
                            Fargo Clinic / MeritCare

                            UUCP: uunet!plains!wind!greg
                            INTERNET: greg%wind.uucp@plains.nodak.edu
                            Phone: 7001-234-2833

`The truest mark of a man's wisdom is his ability to listen to other
 men expound their wisdom.'