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)