Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!kth!sunic!dkuug!freja!skinfaxe!seindal
From: seindal@skinfaxe.diku.dk (Rene' Seindal)
Newsgroups: comp.lang.c++
Subject: Re^2: Help with install c++ 1.2 on a SUN
Message-ID: <4699@freja.diku.dk>
Date: 31 May 89 01:14:17 GMT
References: <6525@sdcsvax.UCSD.Edu> <16123@paris.ics.uci.edu>
Sender: news@freja.diku.dk
Lines: 36

schmidt@ics.uci.edu (Doug Schmidt) writes:

> In article <6525@sdcsvax.UCSD.Edu> rmr@sdcsvax.UCSD.Edu (Robert Rother) writes:
> ++ 
> ++ Can anyone tell me what the special tricks might be to get ATT C++
> ++ Version 1.2 to run on a SUN.  After running the bsd.fix script and
> ++ then running make I get a cfront that hangs.  The version of cfront
> ++ that is produced during the first stage "scratch" works correctly
> ++ but the second version that is produced from the c++ source files
> ++ hangs.  Also the munch programs seems to core dump.
> ++ 
> ++ Any help would be greatly appreciated.

> This problem occurs frequently when porting AT&T's C++ to a new
> machine.  Check out their <stdio.h> file in ./incl/stdio.h.  I'll bet
> you'll find that the fields in struct _iobuf are incorrect for your
> machine.  Take a look at the standard Sun stdio.h file from
> /usr/include.  That will show you how the fields should be defined.

All you will have to do is to change the line

#if vax || u3b || u3b2 || u3b5 || mc68k

in the start of ./incl/stdio.h to

#if vax || u3b || u3b2 || u3b5 || mc68k || sparc || mc68020 || mc68010

Otherwise the first two fields gets swapped.  It has always amazed me why
cfront hangs, instead of dumping core?

Anyway, it all boils down to an attempt to use predefined preprocessor names
in a clever way.  Unfortunately nobody thought about the sparc when the c++
1.2 distribution was made, and they forgot to tell Sun to use the 'right'
names for their predefined preprocessor names.

Rene' Seindal (seindal@diku.dk).