Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!rutgers!boulder!boulder.colorado.edu!grunwald From: grunwald@foobar.colorado.edu (Dirk Grunwald) Newsgroups: gnu.g++ Subject: Re: what and where are the COFF patches for GNU C++ Message-ID: Date: 13 Sep 89 16:22:19 GMT References: <8909121940.AA16299@csusac.csus.edu> Sender: news@boulder.Colorado.EDU Reply-To: grunwald@foobar.colorado.edu Distribution: gnu Organization: University of Colorado, Boulder Lines: 37 In-reply-to: csusac!cvms!ronald@ucdavis.edu's message of 12 Sep 89 19:40:39 GMT I still disagree that this is the way to go --- the entire problem is the Makefile isn't automatically configured. Inserting COFF patches that make use of ifiles is, IMHO, over complicated and needless. Yes, ifiles are nice. But do all coff-like loaders support ifiles? no - for example, the DECstation-3100 and other MIPS-derived machines. They use ecoff, which is compatible with COFF at the level of ``collect,'' but not at the level of ifiles. Using collect is simple, and easier to maintain. I've been using collect on a COFF speaking Encore for over a year. It works just fine. Rather than go though installing these coff changes, we we really need to do is clean up the Makefile to make configuration automatic. This means: + Machines needing collect need to define NO_GNU_LD in their tm.h files + Files using COFF need an explicit symbol in their tm.h files (USES_COFF?) NOTE THAT SVID or whatever isn't always correct. this should be an explicit symbol. + The options needed to compile collect (i.e. -DUMAX) and to compiler crt0+.c and crt1+.c need to be moved into to tm.h + collect.c and ld.c should always be built and installed. ld may not do anything if e.g., NO_GNU_LD is defined, but it simplifies the installation. + whatever changes are needed for e.g., sun3-os4+.h should also be in the tm.h files. Getting these changes in before 1.36 would be tres useful and would end much of the discussion of COFF support for g++.