home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / sun / misc / 3706 < prev    next >
Encoding:
Text File  |  1992-08-15  |  6.4 KB  |  122 lines
  1. Newsgroups: comp.sys.sun.misc
  2. Path: sparky!uunet!decwrl!csus.edu!netcom.com!rfg
  3. From: rfg@netcom.com (Ronald F. Guilmette)
  4. Subject: Re: GCC, Solaris 2.0, Cygnus Support, and a lesson in corporate ethics
  5. Message-ID: <3v7m2cr.rfg@netcom.com>
  6. Date: Sat, 15 Aug 92 15:52:38 GMT
  7. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  8. References: <g1xm!yb.rfg@netcom.com> <WBE.92Aug13012313@crystal.bbn.com>
  9. Lines: 111
  10.  
  11. In article <WBE.92Aug13012313@crystal.bbn.com> wbe@bbn.com (Winston Edmond) writes:
  12. >That's certainly an interesting piece of history about Cygnus, gcc, and the
  13. >port to Solaris 2.0 for SPARCs.  There are some things you didn't discuss,
  14. >though.
  15. >
  16. >First, the $2000 Cygnus solicited was advertised as having two parts:
  17. >(1) (which you mentioned) it would help get gcc ported to Solaris 2.0 and
  18. >    placed on the Catalyst CD-ROM by the shipping date for Solaris 2.0, so no
  19. >    one would have to be without a C compiler;
  20. >(2) (not mentioned) it purchased one year of Cygnus's support at a price 2/3
  21. >    of the usual price for such support.
  22.  
  23. So you are saying that the "standard" price for a Cygnus "support" contract
  24. is $3000, right?  I'm sure that the folks that are paying cygnus $25,000
  25. and/or $100,000 for the same service will be interested to hear that.
  26.  
  27. >Second, part of Cygnus's appeal to potential contributors was that they were
  28. >promising a working version by a specific date -- the Solaris 2.0 ship date.
  29.  
  30. Considering that at the time of their "offer", GCC had already been fully
  31. hosted and targeted to Sparcs (running SunOS 4.1.2) and that it was also
  32. running really well on a variety of other SVR4 systems (e.g. i386, i860,
  33. m88k) due to my work, I don't think that the boys at Cygnus were sticking
  34. their corporate necks out very far in making this "promise".
  35.  
  36. >Sure, we all figured it was likely that gcc would someday be ported to
  37. >Solaris 2.0 for SPARCstations, but, in the absence of knowing with reasonable
  38. >certainty when, the trade-off is a $2000 one-time cost versus loss of
  39. >developers' time and development delays if appropriate tools aren't available
  40. >when needed.  That's easy to decide.
  41.  
  42. I have nothing against buying "insurance", but if one is going to buy
  43. insurance against the possibility of a very unlikely event (e.g. a metorite
  44. hitting your house) I would think that any intelligent person would at
  45. least ask what the probability of such an event is before spending money.
  46.  
  47. >Had you made your porting successes
  48. >more widely known, perhaps some contributors might have chosen not to
  49. >contribute.
  50.  
  51. My porting successes (of GCC to various SVR4 systems) have been widely
  52. known to users of GCC on SVR4/x86, SVR4/i860, and SVR4/m88k systems for
  53. some time.  Anyone who took the time to fetch and inspect a copy of the
  54. (freely available) GCC sources for any version since 2.0 (released quite
  55. some time ago) would have easily been able to see that I think.
  56.  
  57. I'm sorry if you (and others) didn't know about my SVR4 porting work,
  58. but unlike Cygnus, I spend almost all of my time actually writing code,
  59. and almost no time writing press releases which trumpet my successes on
  60. the net and in other forums.
  61.  
  62. >In the end, the one year's support and the guarantee were worth the risk that
  63. >it might all be a waste of money.
  64.  
  65. A "waste of money", eh?  (You said it.  I didn't.)
  66.  
  67. >From: rfg@netcom.com (Ronald F. Guilmette)
  68. >>Something else that struck me as being quite humorous at the time was
  69. >>Cygnus' apparently deliberate reinforcement of the widely held belief
  70. >>(based purely on the uninformed speculation of certain unrelated netnews
  71. >>posters) that Solaris 2.0 would *not* be bundled with an assembler, a
  72. >>linker, standard libraries, or header files.  ... even though *anyone* ...
  73. >>could have easily determined ... that Solaris 2.0
  74. >>would in fact be "bundled" with an assembler, a linker, a set of standard
  75. >>libraries, and a nearly full complement of standard system include files.
  76. >
  77. >Yes, it was common knowledge, posted to various newsgroups at the time, that
  78. >these *would* be in Solaris 2.0.  However, gcc doesn't use the Sun assembler,
  79. >it uses GAS, and its output had better be compatible with whatever the linker
  80. >required.  I had the impression that this was not entirely a solved problem.
  81.  
  82. To put it bluntly, you are confused.  You do not need GAS to use GCC.  Nor
  83. do you need to use the GNU linker.  And contrary to your assertion, running
  84. either GCC or g++ on an SVR4 system is an entirely solved problem.  If you
  85. don't believe that, you should just ask the folks over in comp.unix.sysv386.
  86. I'm sure they will be glad to tell you that many of them have been using
  87. GCC under SVR4 on i386/i486 machines for quite some time.
  88.  
  89. >>They [Cygnus] also ... broke a couple of minor things, and totally disabled 
  90. >>any possibility of using g++ on Solaris 2.0 on Sparcs.
  91. >
  92. >Could you elaborate on what's broken?  Also, why would anything Cygnus did
  93. >prevent g++ from the FSF from ever working on Solaris 2.0 on SPARCs?  I would
  94. >normally assume whatever was broken would eventually get fixed.
  95.  
  96. Richard Stallman and I worked out a very clean scheme for getting C++
  97. file-scope object constructors/destcructors to execute at the right
  98. times via the use of some nice features available as a standard part of
  99. *all* SVR4 linkers (i.e. the .init and .fini sections).  Up until Cygnus
  100. got ahold of it, this scheme was working just fine on all SVR4 systems
  101. *including* ones based on Sparc processors.  The scheme relied on an
  102. assumption that the `gcc' driver program would link your programs
  103. with certain additional .o files (i.e. crtbegin.o and crtend.o) which
  104. are both derived from a file I wrote called crtstuff.c.
  105.  
  106. For most GCC confiugurations which target some SVR4 environment, the gcc
  107. driver program *does* cause these files to be linked into your program.
  108. For reasons which are not apparent however, Cygnus changed the solaris
  109. configuration such that these critical files DO NOT get linked in.  Their
  110. only explanation for doing this was a one line comment which they added
  111. to the `spc-sol2.h' file (which I originally wrote) saying that "we do not
  112. yet support g++ on solaris" (or words to that effect).
  113.  
  114. >On behalf of hackers, developers, and project managers everywhere, I'd like
  115. >to thank you (and everyone else that's been involved, whoever they may be)
  116. >for any and all contributions toward getting gcc to compile SPARC code for
  117. >Solaris 2.0.
  118.  
  119. OK.  I appreciate your thanks, but how about sending me a $2000 check also?
  120. It's the least you can do.
  121.  
  122.