Dec 3100, g++ & libg++
minar at reed.edu
minar at reed.edu
Wed May 8 10:44:14 AEST 1991
In article <1991Apr30.134458.5125 at garfield.cs.mun.ca> tony4 at 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 at bach.cs.byu.edu Wed Feb 20 22:14:11 1991
Date: Wed, 20 Feb 91 14:08:30 MST
>From: thomas at bach.cs.byu.edu (Thomas McNeill)
Message-Id: <9102202108.AA09388 at bach.cs.byu.edu>
To: hueni at 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 at osf.org
Newsgroups: gnu.g++.help,comp.lang.c++
Subject: Re: Undefined symbols in libg++ (DTOR/CTOR)
Message-ID: <9101291658.AA01989 at curley.osf.org>
Date: 29 Jan 91 16:58:27 GMT
Sender: daemon at tut.cis.ohio-state.edu
Followup-To: gnu.g++.help
Distribution: world
Organization: Gatewayed from the GNU Project mailing list help-g++ at prep.ai.mit.edu
Lines: 199
Xref: tut.cis.ohio-state.edu gnu.g++.help:459 comp.lang.c++:11353
| In article <JTSILLAS.91Jan14123809 at bubba.ma30.bull.com> jtsillas at 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 at foobar.colorado.edu) has
supplied patches to bring up G++ with this compiler, and Per Bothner
(bothner at 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 at boulder.Colorado.EDU) and Peter Ham
(ham at 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 at draco.acs.uci.edu
BITNET: iglesias at 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 at 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 at cs.wisc.edu Computer Sciences Dept, U. of Wisconsin-Madison
More information about the Comp.unix.ultrix
mailing list