Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!ncar!boulder!grunwald@foobar.colorado.edu
From: grunwald@foobar.colorado.edu (Dirk Grunwald)
Newsgroups: gnu.g++.bug
Subject: g++ on pmax
Message-ID: <12300@boulder.Colorado.EDU>
Date: 2 Oct 89 20:54:23 GMT
Sender: news@boulder.Colorado.EDU
Reply-To: grunwald@foobar.colorado.edu
Distribution: gnu
Organization: University of Colorado at Boulder
Lines: 31


The latest beta release compiles on the pmax with a little prodding
using gcc 1.36.

I've had it blow off in one file (libg++/src/RNG.cc, using -O), but
haven't traced the bug because there's no debugging information yet.

But, there's no way to link programs, because it looks like support
for collect is gone. Is this correct?

I haven't gotten collect.c to work on the pmax yet - although I've
gotten it to compile (minor renaming of some symbols), it still blows
off by returning a bogus pointer from ldtbread(). If anyone makes more
progress on this front, I'd appreciate it.

I was also thinking that we could eliminate collect installation hassles;
simply have ld++.c be #ifdef'd on NO_GNU_LD to include a call like:

#ifdef NO_GNU_LD
	< body of collect, sending output to out-foo.s >
	system("as -o out-foo out-foo.s");
	system("ld -o the-right-stuff out-foo.o");
#else
	..the read ld
#endif

Then, collect can be eliminated & the gcc interface will be simpler.
Does this sound reasonable? Another approach is to always install collect
but only use it (similar to above) if you've defined NO_GNU_LD.

Dirk Grunwald -- Univ. of Colorado at Boulder	(grunwald@foobar.colorado.edu)