[comp.sys.dec] Dec 3100, g++ & libg++

tony4@garfield.cs.mun.ca (Anthony H. Galway) (04/30/91)

Would someone please post a definitive answer on how to get g++
and libg++ working on a decstation 3100! I am able to get gcc 
working with no problems, and I manage to get g++ compiled, but 
when I attempt to get libg++ compiled I run aground. I can not 
get past String.cc! 

If nothing else, does anyone know where to get a working copy.

BTW: I was using the latest versions of gcc et al.

Thanks
-- 
Anthony H Galway            |\_/|    Practice safe Governing!   
tony4@garfield.cs.mun.ca    (` ')  	 
tony@piglet.engr.mun.ca      |"|                      Use Kingdoms. 

grunwald@foobar.colorado.edu (Dirk Grunwald) (05/01/91)

If you're happy to have your binaries live in
/usr/local/Gnu/{bin,lib}, then snag the following file from
foobar.colorado.edu:pub/Gnu-For-Pmax

  -rw-rw-r--  1 grunwald  5510814 Apr 24 17:36 usr.local.gnu.tar.Z

this is a set of binaries for g++ 1.37.2 (the last one that worked
well for me) g++ 1.37 w/ some changes for the decstation, OSF gcc,
ghostscript 2.1 and some other junk, like a reasonable GDB.

have fund.

minar@reed.edu (05/08/91)

In article <1991Apr30.134458.5125@garfield.cs.mun.ca> tony4@garfield.cs.mun.ca (Anthony H. Galway) writes:
>Would someone please post a definitive answer on how to get g++
>and libg++ working on a decstation 3100! I am able to get gcc 
>working with no problems, and I manage to get g++ compiled, but 
>when I attempt to get libg++ compiled I run aground. I can not 
>get past String.cc! 

Hahha.. this one is a bear. Don't feel bad about not getting it - its not
easy to do. One question for you - do you have gcc working with gdb? I'm
having problems not with gcc-osf-1.9.2.14 and gdb-3.5 patched for MIPS.

The short answer is to get gcc-osf-1.9.2.14 and g++-osf-1.9.2.11.
Later versions of the OSF gcc and g++ might be available somewhere.
However, I'm told that while gcc 1.39.? has been ported to mips
machines, g++ 1.39.? has not, presumably because g++ 1.39.? is too
much of a mess. Pray for gcc 2.0 in which all our problems will be
solved. Either that or complain to DEC about eCOFF.

The easiest place to get these is from foobar.colorado.edu, in the
directory pub/Gnu-For-Pmax. The two relevant files are
gcc-fsf-1.37.1-osf-1.9.2.14.patch.Z and g++-osf-1.9.2.11.tar.Z. You
might also want to get mips-gdb-3.5-diffs.Z, patches for gdb on mips
machines (which I've been having trouble with lately. Sigh.) The OSF
version of gcc for mips fixes some bugs and enables debugging. OSF g++
more or less works, but a few of the libraries don't pass their tests,
and there is no debugging.  There is also some ports for gas, but I
think they write in OSF/1 format, and not Ultrix eCOFF.

Here's some possibly outdated information that might be useful.

>From thomas@bach.cs.byu.edu Wed Feb 20 22:14:11 1991
Date: Wed, 20 Feb 91 14:08:30 MST
>From: thomas@bach.cs.byu.edu (Thomas McNeill)
Message-Id: <9102202108.AA09388@bach.cs.byu.edu>
To: hueni@iam.unibe.ch
Subject: building g++ on the DECstation 3100

Following is the installation notes that I have written myself and
collected from other sources.  Please note that gdb does not really
work with g++ on the DS3100, and that several of the libg++ tests
fail.  I remember that tFix and tRandom fail, and there may be others.
Overall, however, g++ seems to work pretty well.  I hope this
helps you.




Thomas McNeill
1/31/91

			S O U R C E
			===========

The normal source for GNU stuff is either a "local" archive,
gatekeeper.dec.com, or the FSF's actual machine, prep.ai.mit.edu.
The source for the pmax (mips, decstation) stuff is
foobar.colorado.edu (IP address 128.138.243.105) in the
pub/Gnu-For-Pmax directory.


			G C C
			=====

Do the following to install gcc:

1.  Install the source in gcc-osf-1.9.2.14 :

% mkdir gcc-osf-1.9.2.14
% cd gcc-osf-1.9.2.14
% zcat ../gcc-osf-1.9.2.14.tar.Z | tar xvf -

[ Note:  zcat uncompresses a file to the standard output.  The tar
  command does the following:  x means extract, v means verbose (print
  filenames while extracting), f means the next argument is the tar
  file, where "-" means "standard input". ]

[ Note:  "zcat gcc-osf-1.9.2.14.tar.Z | tar tvf -" will give you the
  directory of the tar file. ]


2.  Do everything mentioned in the file INSTALL, namely,
    a.  Edit the Makefile as described in the section
        "Installing GNU CC on MIPS ECOFF-based machines" at the
        end of the Makefile.  That is, uncomment the line
        "MIPS_TFILE = mips-tfile mips-as mips-tdump"
    b.  Configure the source by running
        % config.gcc decstation
    c.  Skip step 4 (involving bison).
    d.  % make >&! ../MAKELOG-1 &
        The "&!" at the end of the ">" mean to redirect standard error
        in addition to standard out, and to overwrite the file if it
        exists.  The trailing "&" makes the compilation run in
        the background.  Even if you log out, it will keep running.
        Later, you can inspect ../MAKELOG-1 to make sure that it
        compiled OK.
    e.  Skip step 6 (I can't find the file README-ENCAP).
    f.  % make stage1
    g.  % make CC=stage1/gcc CFLAGS="-g -O -Bstage1/" >&! ../MAKELOG-2 &
    h.  % make stage2
    i.  % make CC=stage2/gcc CFLAGS="-g -O -Bstage2/" >&! ../MAKELOG-3 &
    j.  % foreach file (*.o)
        ? echo $file
        ? cmp $file stage2/$file 8 8
        ? end
        This compares stage 2 and stage 3.  If any difference are
        reported, then something is wrong.  The "8 8" on the end of
        the cmp command line means to skip the first 8 bytes of each
        file.  The first 8 bytes of a COFF format .o file are a
        time stamp, and are guaranteed to be different.
    k.  If everything was successful, (inspect ../MAKELOG-1,
        ../MAKELOG-2, ../MAKELOG-3 and the results of the foreach
        described in step j), then do
        % make install
    i.  Remove the unneeded files generated during compilation:
        % make clean
        % rm -r stage1
        % rm -r stage2

3.  Fix the non-ANSI include files.  The program "fixincludes" looks
    at all the include files, ANSI-fies them, and installs them in
    /usr/local/lib/gcc-includes.  gcc and g++ look there first for
    header files:

    % fixincludes

4.  Made a symbolic link with the name "gcc" to gcc-osf-1.9.2.14 :

% cd ..
% ln -s gcc-osf-1.9.2.14 gcc


5.  Remove the MAKELOG files:
    % rm MAKELOG-1 MAKELOG-2 MAKELOG-3

6.  Make sure that /usr/local/bin is in the path so that gcc can be found.




			G + +
			=====

Do the following to install g++:

1.  Install gcc (see above).

2.  Install the source.  Note that unlike gcc, all of the files in the
    g++ tar file have the same directory prefix, e.g.,

rwxrwxr-x11746/101       0 Nov 30 00:34 1990 g++-1.37.2/
rw-rw-r--11746/101   71294 Aug  6 08:26 1990 g++-1.37.2/ChangeLog
rw-rw-r--11746/101  143023 Jan  7 09:17 1990 g++-1.37.2/ChangeLog89
rw-rw-r--11746/101   80287 Jun 23 13:03 1990 g++-1.37.2/HINTS
rw-rw-r--11746/101    6697 Nov 18 17:37 1989 g++-1.37.2/Imakefile
rw-rw-r--11746/101   25667 Nov 28 10:16 1990 g++-1.37.2/Makefile
rw-rw-r--11746/101   11882 Aug  4 23:51 1990 g++-1.37.2/README
rw-rw-r--11746/101   18144 Jan 30 06:59 1990 g++-1.37.2/case.c

    Thus running tar in the directory /usr/local/src/GNU will
    create the directory /usr/local/src/GNU/g++-1.37.2 and place
    all of the source there.  Therefore we run tar from
    /usr/local/src/GNU instead of creating /usr/local/src/GNU/g++-1.37.2,
    cd-ing to it, and then running tar.

    % zcat g++-osf-1.9.2.11.tar.Z | tar xvf -
    % cd g++-1.37.2

3.  The file INSTALL is simply a symbolic link to ./gcc/INSTALL, so
    it is less helpful than it might be.  However, to install, you
    do roughly the same things:
    a.  Configure the source by running
        % config.g++ decstation
    b.  Edit the Makefile:
        % mv Makefile Makefile.orig
        % cp Makefile.orig Makefile
        % vi Makefile

        Uncomment the line:
        COFFLAGS = -DUSE_COLLECT -DEXTENDED_COFF

	Comment out the line:
	# all: crt1+.o g++ cc1plus ld++ g++filt # collect crt0+.o

	Uncomment the line:
	all: g++ cc1plus collect # crt0+.o crt1+.o

	Change the line:
	prefix=/tools2/gnu
	to:
	prefix=/usr/local

    c.  I have read that the gcc.c distributed with g++ is faulty
	and that the gcc gcc.c should be used instead.  Thus:
	% mv gcc.c gcc.c.orig
	% ln -s ../gcc/gcc.c gcc.c
    d.  Make g++:
	% make >&! ../g++-1.37.2.MAKELOG &
    e.  The Makefile fails when trying to compile "collect".  Use the
	following command line to build it manually:
	% gcc -o collect \
	  -g -DGATHER_STATISTICS -O -DUSE_COLLECT -DEXTENDED_COFF \
	  -B../gcc-test/ -DFIELD_XREF -I. -I./config collect.c -lg -lc
    f.  Run "make" one more time to ensure that everything has been
	built:
	% make
    g.  Install the binaries in /usr/local/bin and /usr/local/lib:
	% make install
    h.  Make the g++ preprocessor (cccp) and install it as the
	gcc preprocessor, gcc-cpp (cpp stands for "C preprocessor").
	It appears that the gcc cpp is not robust enough to handle
	g++:
	% make cccp
	% mv /usr/local/lib/gcc-cpp /usr/local/lib/gcc-cpp.gcc
	% cp cccp /usr/local/lib/gcc-cpp
    i.	The last thing to do is remove all of the .o files, etc.,
	generated during the processing of making g++.  This is
	done by:
	% make realclean
	I did not do this until after I had made and installed
	libg++, just in case libg++ needed something that
	make realclean deletes.




			L I B G + +
			===========

Do the following to install libg++:

1.  Install the source.  Like g++, the libg++ tar files creates its
    own directory:

    % zcat libg++-1.37.0.tar.Z | tar xvf -
    % cd libg++-1.37.0

2.  Compile the library, run the tests, and install:
    a.  Edit the Makefile:
        % mv Makefile Makefile.orig
        % cp Makefile.orig Makefile
        % vi Makefile

	Comment out the line:
	# PWD := $(shell pwd)

	Uncomment the following line and change it to:
	PWD=/usr/local/src/GNU/libg++-1.37.0

	Change the line:
	prefix =/usr/gnu
	to:
	prefix =/usr/local

	Uncomment the line:
	XTRAFLAGS = -DNO_LIBGXX_MALLOC

	Comment out the line:
	# PIPE_AS= -pipe
	and uncomment the following line:
	PIPE_AS=
    b.  Patch the libraries:
	There is a patch for the curses header file in the file
	/usr/local/src/GNU/libg++.diffs.  It says it is for the file
	CursesW.h, but there is no such file.  The name of the file
	has apparently been changed to CursesWindow.h, and it is
	located in g++-1.37.2/g++-include.  The patch also does
	not match CursesWindow.h exactly, although it is possible
	to figure out where the patch should be applied and
	apply it by hand.
    c.	Run make:
	% make all
	This will attempt to make the library, make the tests,
	run the tests, and check the tests.  However, not all
	of the tests will successfully run, and after the first
	one fails (with a segmentation fault), checking halts.
	You should be able to figure out from tests/Makefile
	at the label "runtests:" how to run the tests yourself,
	save the output, and then check it.  In particular, if
	you write a csh script to run the tests, the script will
	not stop just because of a seg fault in a program that
	it spawns.
    d.	You should expect the output to be different for the
	tests tRational, tRandom and tFix.
    e.	Install:
	% make install
    f.	Delete the files created during the installation process:
	% make clean

========================================================================

Here is a file of tips that I picked up off the net:


Path: physc1!byuvax!byuvm!cunyvm!psuvm!ysub!tut.cis.ohio-state.edu!osf.org!meissner
>From: meissner@osf.org
Newsgroups: gnu.g++.help,comp.lang.c++
Subject: Re: Undefined symbols in libg++ (DTOR/CTOR)
Message-ID: <9101291658.AA01989@curley.osf.org>
Date: 29 Jan 91 16:58:27 GMT
Sender: daemon@tut.cis.ohio-state.edu
Followup-To: gnu.g++.help
Distribution: world
Organization: Gatewayed from the GNU Project mailing list help-g++@prep.ai.mit.edu
Lines: 199
Xref: tut.cis.ohio-state.edu gnu.g++.help:459 comp.lang.c++:11353
 
| In article <JTSILLAS.91Jan14123809@bubba.ma30.bull.com> jtsillas@bubba.ma30.bull.com (James Tsillas) writes:
| >Hello, I have ported g++ and libg++ but I keep getting this error when
| >trying to link:
| >
| >        g++  fib.o -L../../src -lg++ -lm  -o fib
| >undefined                       first referenced
| > symbol                             in file
| >___DTOR_LIST__                      /lib/libg++.a
| >___CTOR_LIST__                      /lib/libg++.a
|
| I had this same problem when I was seting up the OSF's version of g++/gcc.
| If you are running this version, the latest release on foobar.colorado.edu
| supposedly fixes this problem.
 
There is a off-by-one error in the gcc.c distributed with the g++
patches -- just use the current gcc.c in the latest GCC release.  Here
is my current blurb sheet about the stuff there.
 
As part of my work for the Open Software Foundation, I have been
supporting GCC for MIPS based platforms.  I have fixed tons of bugs,
and added things like full debug support and better code to omit the
frame pointer.  Dirk Grunwald (grunwald@foobar.colorado.edu) has
supplied patches to bring up G++ with this compiler, and Per Bothner
(bothner@cs.wisc.edu) provided gdb patches.
 
I maintain a mailing list to get the GCC patches automatically.  Send
me mail if you want to get on the list.
 
In addition, Dirk has allowed me to put copies of the compiler on his
machine (foobar.colorado.edu, IP address 128.138.243.105) if you can
get sources via anonymous FTP in the pub/Gnu-For-Pmax directory.  Here
is a list of available files as of December 15th:
 
-rw-r--r--  1 0        system    1721295 Nov 11 02:59 g++-osf-1.9.2.11.tar.Z
-rw-r--r--  1 0        system       8944 Nov 11 02:59 gcc-1.8.1.5-Iris3.3.shar.Z
-rw-r--r--  1 ftp      system     510215 Dec 15 10:34 gcc-fsf-1.37.1-osf-1.9.2.14.patch.Z
-rw-r--r--  1 0        system      39757 Nov 11 02:59 gcc-osf-1.9.2.12-osf-1.9.2.13.patch.Z
-rw-r--r--  1 ftp      system      27219 Dec 15 10:34 gcc-osf-1.9.2.13-osf-1.9.2.14.patch.Z
-rw-r--r--  1 ftp      system    1290307 Dec 15 10:49 gcc-osf-1.9.2.14.changed-files.tar.Z
-rw-r--r--  1 ftp      system    2788255 Dec 15 10:42 gcc-osf-1.9.2.14.tar.Z
-rw-r--r--  1 0        system      59587 Nov 11 02:59 gdb-3.5-mips.patch.Z
-rw-r--r--  1 ftp      system     682738 Dec 31  1990 osfrose-tools.new.tar.Z
-rw-r--r--  1 ftp      system    3654053 Dec 13 13:36 osfrose-tools.tar.Z
-rw-r--r--  1 0        system        553 Nov 11 02:59 split.c
 
The currently known bugs are (12/15/1990):
 
   1)	malloc.c doesn't work properly in libg++, specify the
	following in the Makefile:
 
		XTRAFLAGS = -DNO_LIBGXX_MALLOC
 
   2)	You must configure g++ with the following in Makefile:
 
		COFFFLAGS = -DUSE_COLLECT -DEXTENDED_COFF
 
	and the all target should be:
 
		all: g++ cc1plus collect # crt0+.o crt1+.o
 
   3)	G++'s Makefile doesn't run in subdirectories yet.
 
   4)	Ignore the messages (best as I can tell) about duplicate
	functions lmask__Fi, rmask__Fi, BSnew__Fi in libg++ -- these
	are inlines that aren't getting inlined.
 
   5)	The tFix and wrapper libg++ tests are known not to work.  I
	also had problems with tRandom.
 
   6)	Debugging isn't completely supported for G++ (it is for GCC).
 
   7)	Passing structures that are unaligned (ie, contain only shorts
	and/or chars) will not generate the correct code.
 
 
George Hartzell (hartzell@boulder.Colorado.EDU) and Peter Ham
(ham@cs.stanford.edu) were looking into better G++ debug support.
 
Here is a comment from Mike Iglesias:
 
I've been able to build g++ and libg++ under ultrix 4.1.  However, I
wasn't able to build groff v0.6 - I got the same seg fault.  I was
able to build groff v0.5 with no problems, and it seems to work fine
for what I've used it for so far (printing troff documents on a Postscript
printer).
 
[meissner comment: I seem to remember the segfault is caused in
dumping out the debug symbol table, if you don't compile for debugging
there was no segfault]
 
There are some problems with building libg++ - a couple of .h files
in g++-include are named wrong (LogNormal.h should be LogNorm.h, for
example).  You can apply the patch at the end of this message to
CursesW.h to get programs that use it (like the tCurses test) to
build properly.  I think the main thing to do when building libg++
is to not use the malloc that comes with libg++ (look in the Makefile
for how to use the Ultrix one).
 
As for g++, I don't remember having a lot of problems with it, but it
was a few weeks ago when I did it, so I may be forgetting something.
I followed Dirk Grunwald's directions (posted here a few weeks back).
 
 
Mike Iglesias
University of California, Irvine
Internet:    iglesias@draco.acs.uci.edu
BITNET:      iglesias@uci
uucp:        ...!ucbvax!ucivax!iglesias
 
*** CursesW.h.orig	Fri Jun 22 03:27:44 1990
--- CursesW.h	Sat Dec 29 10:10:48 1990
***************
*** 140,146 ****
--- 140,148 ----
    int            scroll();
    int            scrollok(cbool bf);
    int            touchwin();
+ #ifndef ultrix
    int            touchline(int y, int sx, int ex);
+ #endif
    int            refresh();
    int            leaveok(cbool bf);
    int            flushok(cbool bf);
***************
*** 151,157 ****
    int            overlay(CursesWindow &win);
    int            overwrite(CursesWindow &win);
 
! #ifndef DGUX
    int            touchoverlap(CursesWindow &win);
  #endif
 
--- 153,159 ----
    int            overlay(CursesWindow &win);
    int            overwrite(CursesWindow &win);
 
! #if !defined(DGUX) && !defined(ultrix)
    int            touchoverlap(CursesWindow &win);
  #endif
 
***************
*** 214,220 ****
    return ::scroll(w);
  }
 
! #ifndef DGUX
  inline int CursesWindow::touchoverlap(CursesWindow &win)
  {
    return ::touchoverlap(w, win.w);
--- 216,222 ----
    return ::scroll(w);
  }
 
! #if !defined(DGUX) && !defined(ultrix)
  inline int CursesWindow::touchoverlap(CursesWindow &win)
  {
    return ::touchoverlap(w, win.w);
***************
*** 296,305 ****
--- 298,309 ----
    return ::wmove(w, y, x);
  }
 
+ #ifndef ultrix
  inline int CursesWindow::touchline(int y, int sx, int ex)
  {
    return ::touchline(w, y, sx, ex);
  }
+ #endif
 
  inline int CursesWindow::mvcur(int sy, int ey, int sx, int ex)
  {
 
 
Here is a posting from Per Bothner about GDB:
 
New patches to port gdb to MIPS-based machines (including
DECstations and SGI Iris) are now available by
anonymous ftp from sevenlayer.cs.wisc.edu (128.105.8.11)
in pub/mips-gdb-3.5-diffs.Z. Uncompress this file, and
then use patch applied to a virgin gdb-3.5 distibution.
 
The changes are minor, so don't bother if you already
have gdb running. The main differences are better support
for Ultrix 4.0, as well as support for SGI Iris core files
(thanks to David B.Anderson (davea@sgi.com)). (Also, this
time I remembered to give the -c option to diff!)
 
The gdb port uses native ECOFF object file format,
which is emitted by cc, gcc, and g++. Unfortunately,
ECOFF doesn't really support g++, so gdb won't be very
useful for g++ programs.
 
Gdb 4.0 will have mips support bundled in. Version 4.0
is being actively worked on, but needs major cleaning
up before it can be released.
 
	--Per Bothner
bothner@cs.wisc.edu Computer Sciences Dept, U. of Wisconsin-Madison