Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!deimos.cis.ksu.edu!ksuvax1.cis.ksu.edu!sridhar
From: sridhar@ksuvax1.cis.ksu.edu (Srinivasan Sridhar)
Newsgroups: comp.lang.c++
Subject: C++ porting to AT&T machines
Message-ID: <2224@deimos.cis.ksu.edu>
Date: 28 Jun 89 18:08:33 GMT
Sender: news@deimos.cis.ksu.edu
Reply-To: sridhar@ksuvax1.cis.ksu.edu (Srinivasan Sridhar)
Distribution: usa
Organization: Kansas State University, Dept of Computing & Information Sciences
Lines: 53

Hi netters,

I'm new to this newsgroup and being a c++ user, I am pretty impressed
with the kind of work people are doing in c++.  Seems like the reluctance
to c++ is wearing off!

After porting c++ version 1.2.1 from AT&T to our VAX running on BSD 4.2
with very little or no problems and after porting the translator to our
Vax Workstation 2000 running on ULTRIX BSD 4.2, I seem to have problems 
porting it to our AT&T 3B15's and our AT&T 3B2's!!

The following lists the problems I have encountered in porting the translator:
(remember, I am porting from scratch, we do not have standard distribution 
media on diskettes that AT&T sells for the 3B family).

1.  Executed "make scratch" and using scratch cfront, libC.a and munch
    and executed top-level "make".  Generated cfront, libC.a and patch
    but it seems that cfront doesn't seem to work.  "make test" does not 
    compile - the error returned is:

	internal <<cfront 1.21 2/16/87>> error:w1 error

2.  Used the working cfront, etc. on our VAX to generate scratch files
    ("make fillscratch" on the vax) using the "+x $(SZAL) option in the
    top level makefile where  SZAL is the size-alignment of the 3B2's.

    Moved the scratch files to the 3B2's and executed the makefiles again.

	Result - same error (internal << ....)

3.  Used a working c++ translator on a 3B2 to compile scratch files and
    make cfront, patch, libC.a.

	Result - same error.

    Used the working translator (above) to compile src files and generate
    cfront ...etc.

	Result - you guessed it - same error.


    What beats me is that AT&T has custom written the source code to
    primarily fit AT&T machines.  Though the distribution media is different
    (they sell compiled translator components), I don't see how this
    is different from site compiled code.

    I am sure that some of you have faced similar problems.  If there
    is a quirk in the implementation, some hidden fixes, or there is 
    something basically wrong in what I am doing, I would greatly
    appreciate your helpful tips.  Thanks in advance.

			--sridhar (grad. student in Kansas State University
					Dept. of Computer Science)