Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!boulder!boulder.colorado.edu!grunwald From: grunwald@foobar.colorado.edu (Dirk Grunwald) Newsgroups: gnu.g++ Subject: Re: COFF support, IMHO Message-ID: Date: 14 Sep 89 20:48:01 GMT References: <8909141842.AA10402@csusac.csus.edu> Sender: news@boulder.Colorado.EDU Reply-To: grunwald@foobar.colorado.edu Distribution: gnu Organization: University of Colorado, Boulder Lines: 29 In-reply-to: csusac!cvms!ronald@UCDAVIS.EDU's message of 14 Sep 89 18:42:34 GMT In article <8909141842.AA10402@csusac.csus.edu> csusac!cvms!ronald@UCDAVIS.EDU writes: As you noted, my patches support real AT&T COFF loaders, and not coff-like imitations like "ecoff". Real COFF loaders can already do what collect does anyway. Besides, I personally distribute and support my patches. I haven't seen a supported collect yet that allows me to use my libraries un-encapsulated --- Consider it put. Look at any version of G++ since about 1.34. I've been using collect.c with native Encore UMAX (which uses a full-blown COFF system) for about a year now. We've also used it on an AT&T SYSVR3 '386 system. I believe that SDB_DEBUGGING_INFO and COFF go hand in hand. I'll be glad to change my patches should some vendor prove me wrong. --- I'm not completely certain about SDB_DEBUGGING_INFO and COFF -- for example, the MIPS compiler produces COFF output, but they use DBX. It may just be a SDB-information groking DBX, but I don't know yet. Because of the current lack of support in C++ for SDB (COFF) symbol generation, and the current lack of desire to support COFF in FSF products, I don't see (IMHO) official COFF support in g++ for a while. --- the proposed changes are simiply configuration management changes - right now, g++ has a pretty lashed together makefile - this could be fixed by def'ing a few new symbols in tm.h