srodawa@vela.acs.oakland.edu (Ron Srodawa) (11/21/90)
The good news is I managed to build and install g++ today. The bad news is it finished five minutes before going off to teach classes and I can't get back to it until Monday. If testing shows we have a good compiler, I'll put it up for anonymous ftp on unix.oakland.edu (141.210.180.2). It wasn't hard, but it sure wasn't easy! I started by installing the new SCO Development System Upgrade..Release 2.3.1b. (This is available for free from SCO.) Then I updated that with SLS lng244. I installed the new gcc, gas, gdb (two diskette version) from Ron and Steve at RoboBar. I previously installed bison. Next I brought down the full gas source and built it per the instructions in the Xenix release. After that I brought down the gcc-1.37.1 source and built that. Here I had some problems. Patch blew up on one of the files and I ended up doing the edit by hand. (Some error messages then an IOT error.) The first few stabs didn't work (include file problems..probably brought on by the latest SCO updates.) Finally I generated gcc again (using gcc as the compiler and keeping -tradition as a flag.) I went all the way through stage2. Two modules don't compare, but what the heck, each time they are a little different. I didn't install this, using the RoboBar binaries instead. I bypassed building gdb as it isn't required for installing g++. Now I brought down g++-1.37.1 source ad applied the set of patches communicated by Steve and Ron a bit ago. I wrote some sh loops to get all the "ln"'s right, including config. I had a touch more trouble with include files (size_t) when building gnulib2. Finally I let the whole giant make loose. It bombed on the compile for collect.c (there was no source file specified). Fixed that and we got ourselves a compiler. I'm a little concerned because size_t seems to be unsigned int in Xenix includes, but unsigned long in gcc includes. Again, if it works, I'll make it available. Ron. -- | Ronald J. Srodawa | Internet: srodawa@unix.secs.oakland.edu | | School of Engineering and CS | UUCP: srodawa@egrunix.UUCP | | Oakland University | Voice: (313) 370-2247 | | Rochester, Michigan 48309-4401 | |
NU013809@NDSUVM1.BITNET (Greg Wettstein) (11/24/90)
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.'