meissner@osf.org (01/30/91)
| 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