ronald@UCDAVIS.EDU (09/15/89)
| 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. 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 (i.e. I am not forced to use the GNU binutils; although that doesn't mean that one doesn't exist). My posting was to inform about availability only and not an invitation to discuss the "right" way to do it. My patches are available now and they work. So, if you'll pardon the colloquialism, put up or shut up. | 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. 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. | + 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++. 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. Enough said! -- Ronald Cole | uucp: cvms!ronald voice: +1 916 895 8321 Senior Software Engineer | internet: csusac!cvms!ronald@ucdavis.edu CVM Systems +---------------------------------------------------- OVER the underpass! UNDER the overpass! Around the FUTURE and BEYOND REPAIR!!
grunwald@foobar.colorado.edu (Dirk Grunwald) (09/15/89)
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