dl@ROCKY.OSWEGO.EDU (Doug Lea) (05/08/89)
A preliminary version of libg++-1.35.0 is now on yahi.stanford.edu. It contains the `extern "C"' modifications needed for the most recent g++-1.35.0-, as well as other miscellaneous fixes and updates. The patches Michael posted to bug-g++ Sunday (7May) are necessary to compile it. Please let me know if there are any other problems. -Doug
tale@pawl.rpi.edu (David C Lawrence) (05/10/89)
In article <8905081600.AA11895@rocky> dl@ROCKY.OSWEGO.EDU (Doug Lea) writes:
Doug> Please let me know if there are any other problems.
Yep.
--------problems-----------
Script started on Wed May 10 03:11:53 1989
ault has logged on ttyp4.
/appl/imagine2/emacs/libg++
imagine:gnu (1) make libg++.a
(cd src; make GXX="g++" CC="gcc")
g++ -v -g -O -fchar-charconst -I../g++-include -I.. -fstrength-reduce -fsave-memoized -mgnu -c builtin.cc
g++ version 1.35.0-
/appl/life1/gnu/lib/gcc-cpp -+ -v -I../g++-include -I.. -undef -D__GNU__ -D__GNUG__ -Dmc68000 -Dsun -Dunix -D__mc68000__ -D__sun__ -D__unix__ -D__OPTIMIZE__ -D__HAVE_68881__ -Dmc68020 builtin.cc /tmp/cca09633.cpp
GNU CPP version 1.35
/appl/life1/gnu/lib/gcc-cc1plus /tmp/cca09633.cpp -quiet -dumpbase builtin.cc -mgnu -fchar-charconst -fstrength-reduce -fsave-memoized -opt -version -G -o /tmp/cca09633.s
c++: Invalid option `gnu'
GNU C++ version 1.35.0- (68k, MIT syntax) compiled by GNU C version 1.35.
*** Error code 1
make: Fatal error: Command failed for target `builtin.o'
Current working directory /appl/imagine2/emacs/libg++/src
*** Error code 1
make: Fatal error: Command failed for target `libg++.a'
Exit 1
/appl/imagine2/emacs/libg++
imagine:gnu (2) exit
script done on Wed May 10 03:12:20 1989
-------problems-----------
This could very well be that I do not have a working g++, I really
would like to know. After fighting with the highest version (1.34.2)
of g++ on prep for hours, I checked the newsgroups and found out that
my problem was that I was using GCC 1.35 with 1.34 g++. So I got the
g++.xtar.Z and libg++.xtar.Z from Stanford. Things went much smoother
(although still quite slow) on the G++ build, but I am confused about
some of the different message regarding Suns. My two primary
lack-of-understanding items are a) in the Makefile should I add
-DNO_GNU_LD? (I know it says "could", but _should_ I?) and b) what
do I have to do about crt0+.o?
Here is the way it is all mapped out: Sun 3's, OS 4.0.1. GNU sources
go into /appl/life1/gnu/{bison,gcc,g++,grep,...}. GNU binaries are in
/appl/life1/gnu/bin. All references to install things in
/usr/local/lib get changed to put them in /appl/life1/gnu/lib.
A recent message to gnu.g++.bug suggests that on Suns you have to
change tm.h, but doesn't say how to change it (if indeed I need to).
The HINTS file also says something about Mrt0.o and says I should
change standard_starfile_prefix ... should I? Or are things right the
way they are as long as I have declared all the paths properly in the
Makfiles?
I don't know why this has been so hard for me. Maybe I'm just tired.
Maybe I'm just stupid. I sure would appreciate a better recipe for
getting this thing working on our pretty standard architecture/os
here though.
Dave
--
tale@rpitsmts.bitnet, tale%mts@itsgw.rpi.edu, tale@pawl.rpi.edudl@ROCKY.OSWEGO.EDU (Doug Lea) (05/10/89)
>> /appl/life1/gnu/lib/gcc-cc1plus /tmp/cca09633.cpp -quiet -dumpbase builtin.cc -mgnu -fchar-charconst -fstrength-reduce -fsave-memoized -opt -version -G -o /tmp/cca09633.s >>c++: Invalid option `gnu' Sorry, I placed the `-mgnu' flag in GFLAGS in the makefiles, without realizing that it is vax-specific. People running on anything other than a Vax using the gas assembler should remove this switch. -Doug
tiemann@YAHI.STANFORD.EDU (Michael Tiemann) (05/10/89)
If you read the README, it is quite clearly stated what happens when you try to mix and match versions of GNU CC and GNU C++. Only add NO_GNU_LD if you are *not* on a Sun2/3/4, VAX, or other Berkeley-like machine. You have to install crt0+.o where ld++ can locate it, typically /usr/local/lib/crt0+.o. If the paths given correctly to the Makefile, things should work out. Michael