Xref: utzoo gnu.g++:938 comp.text:6984 gnu.misc.discuss:1175 Path: utzoo!utgpu!watserv1!watmath!uunet!mcsun!ukc!edcastle!dcl-cs!aber-cs!odin!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: gnu.g++,comp.text,gnu.misc.discuss Subject: Re: g++/groff for i386? Message-ID: Date: 5 Jul 90 15:20:42 GMT References: <1990Jul3.004744.11110@uokmax.uucp> <578@vidiot.UUCP> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 51 In-reply-to: brown@vidiot.UUCP's message of 4 Jul 90 01:42:10 GMT In article <578@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes: Welcome the the GNU g++ installation fustration club. It has never taken me more than a couple of hours to get G++ running; all I have done has been to compile it with 'cc -O -W2,-y0', link it with the '-lPW' switch, and use COFF support. I have also found the time to slightly improve (some releases back) support for shared libraries, linking with holes, etc... Very few problems even there. My next project, when I reinstall it (I am waiting 2.0), is to get rid of the collect pass and put in the COFF .init .fini section support as already done by others (Grunwald?). Even there I expect very little sweat. What's all this fuss about G++ and SysV386, I always ask myself. I too want to get groff running, but can't because of the same ld.c problems. I had others as well, that wasted about 6 hours of time. I have written to the author and am awaiting an answer. Only because you probably insist on using the dreaded COFF encapsulation mode. Now that somebody has posted (THANKS!) it, and you have COFF compatible gas and COFF stabs for gdb (on sequent.kent.edu, in directory pub/unix386, there is no reason not to use COFF and the AT&T ld and shared libraries. I would make installation much easier if the GNU team would use the configure program package, like rn and elm. [ ... ] I believe that the GNU team should very seriously consider this installation aid. They will not, because the GNU team is seriously interested in getting the GNU OS off the ground, not supporting other OSes. The rely on the public to care for this, as noted above. I want however to repeat my plea for the GNU authors to use GNU RCS to maintain versions, to always release software with a X.Y release number (and not longer), and to have all GNU RCS headers contain that number, so that: * people doing independent modifications can checkin sources at the X.Y level and put their own mods on branches * authors can release diff upgrades simply by running rcsdiff -c * modifications done on the branches can be incorporate din the mainstream or in later releases of the mainstream by use of patch and checkin or with rcsmerge. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk