🚀 go-pugleaf

| 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