These changes clean things up a bit, and improve Solaris cross
[deliverable/binutils-gdb.git] / sol-rel.texi
CommitLineData
5898af2c
DHW
1\input texinfo
2@c
3@c This file may require a nonstandard texinfo.tex to format; if you
4@c need it, please contact Cygnus Support (email editor-in-chief@cygnus.com)
5@setfilename SOLARIS2.info
6@c
7@c This file describes a Cygnus Solaris Release (Developer's Kit).
8@c
9@c Copyright (C) 1991, 1992 Cygnus Support
10@c This text may be freely distributed under the terms of the GNU
11@c General Public License.
12@c
13@c $Id$
14@c
15@iftex
16@c The include file "texiplus.tex" is in the texinfo/cygnus dir, and
17@c implements Cygnus modifications to the texinfo manual style.
18@input texiplus
19@c The include file "smpklug.texi" is a kluge to deal with local
20@c document production issues at Cygnus; it's safe to comment out this
21@c line if you don't have (or don't want) the file.
22@input smpklug.texi
23@smallbook
24@cropmarks
25@finalout
26@settitle Release Notes
27@setchapternewpage on
28@c
29@end iftex
30
31@titlepage
32@title Release Notes
33@sp 3
34@table @strong
35@item Cygnus Support Developer's Kit
36@item Release 1.0 for Solaris-2
37@end table
38@author Cygnus Support
39@page
40
41@tex
42\def\$#1${{#1}} % Kluge: collect RCS revision info without $...$
43\xdef\Rmanvers{{\it Release Notes (Solaris-2 Developer's Kit)}, \$Revision$} % *NOT* for use in headers, footers
44{\parskip=0pt \hfill Cygnus Support\par \hfill \Rmanvers\par \hfill
45\TeX{}info \texinfoversion\par }
46\global\def\manvers{Solaris-2 Rel 1.0}
47@end tex
48
49@vskip 0pt plus 1filll
50This product includes software developed by the University of
51California, Berkeley and its contributors.
52
53This note is copyright @copyright{} 1992 Cygnus Support
54
55Permission is granted to make and distribute verbatim copies of
56this manual provided the copyright notice and this permission notice
57are preserved on all copies.
58
59Permission is granted to copy and distribute modified versions of this
60manual under the conditions for verbatim copying, provided also that
61the entire resulting derived work is distributed under the terms of a
62permission notice identical to this one.
63
64Permission is granted to copy and distribute translations of this manual
65into another language, under the above conditions for modified versions.
66
67@end titlepage
68
69@c PROOFREADING: set FIXMES to include FIXME text in formatted
70@c output
71@clear FIXMES
72
73@ifinfo
74@node Top
75@top Solaris-2 Developer's Kit release 1.0
76
77@menu
78* Introduction:: Overview
79* Contributors:: GCC for Solaris-2 exists thanks to these people
80* Versions:: Closest FSF Versions
81* New:: New in This Release
82* Limits:: Limitations and Warnings
83@end menu
84
85This product includes software developed by the University of
86California, Berkeley and its contributors.
87
88This file is copyright @copyright{} 1992 Cygnus Support
89
90Permission is granted to make and distribute verbatim copies of
91this manual provided the copyright notice and this permission notice
92are preserved on all copies.
93
94Permission is granted to copy and distribute modified versions of this
95manual under the conditions for verbatim copying, provided also that
96the entire resulting derived work is distributed under the terms of a
97permission notice identical to this one.
98
99Permission is granted to copy and distribute translations of this manual
100into another language, under the above conditions for modified versions
101@end ifinfo
102
103@node Introduction
104@chapter Overview
105
106@table @strong
107@item Cygnus Support Developer's Kit
108@item Solaris-2 Release 1.0
109@end table
110
111Sun has unbunded its compilers---selling them separately from the
112Solaris 2.0 operating system. Many Sun users were unhappy that their
113next upgrade might take away their C compiler.
114
115In response, Cygnus Support ported the GNU C compiler and supporting
116tools to Solaris 2.0. The result is a full set of development
117tools---ANSI and traditional C compiler (with supporting libraries),
118debugger, parser generator, and lexical analyzer generator---freely
119available to everyone.
120
121The GNU C compiler can be used to compile any kind of program: public
122domain, copyleft, or proprietary. Your binaries have the same
123copyright status as your sources and libraries. The only provision of
124the GNU General Public License that applies to users of the compiler
125(as opposed to people who make copies of the compiler, or modify it)
126is the lack of warranty (section 11 and 12). FSF does not provide a
127warranty to anyone, but Cygnus gives a 1-year limited warranty (a year
128of support) to customers.
129
130@node Contributors
131@chapter Contributors to GNU C for Solaris-2
132
133Cygnus Support and the FSF are grateful to the forward-looking individuals and
134organizations that sponsored this project.
135
136@noindent
137We are glad to be able to thank publicly:
138
139@itemize @bullet
140@item
141Amoco Production Company (Houston, Texas)
142
143@item
144BBN Communications (Cambridge, Massachusetts)
145
146@item
147Boston Technology (Wakefield, Massachusetts)
148
149@item
150Cirrus Logic (Fremont, California)
151
152@item
153Compaq Computer Corporation (Houston, Texas)
154
155@item
156Deere & Company (Moline, Illinois)
157
158@item
159ELF Commnuications (San Francisco, California)
160
161@item
162European Computer-Industry Research Centre GMBH (Munich)
163
164@item
165Fidelity Investments (Boston, Massachusetts)
166
167@item
168FTP Software, Inc. (Wakefield, Massachusetts)
169
170@item
171Gallagher & Robertson (Oslo, Norway)
172
173@item
174GTE Laboratories (Waltham, Massachusetts)
175
176@item
177Ingres Corporation (Alameda, California)
178
179@item
180Inland Sea (Dexter, Michigan)
181
182@item
183Los Alamos National Laboratory (Los Alamos, New Mexico)
184
185@item
186Miller/Howard Investures (Cobleskill, New York)
187
188@item
189MIT Lincoln Laboratory (Lexington, Massachusetts)
190
191@item
192NASA Lewis Research Center (Cleveland, Ohio)
193
194@item
195Optimation Software (Melbourne, Australia)
196
197@item
198PFU Limited (Tokyo)
199
200@item
201Philips Laboratories (Briarcliff Manor, New York)
202
203@item
204Pure Software (Los Altos, California)
205
206@item
207Qualix Group, Inc. (San Mateo, California)
208
209@item
210Schlumberger-Doll Research (Ridgefield, Connecticut)
211
212@item
213Kevin Sheehan (Melbourne, Australia and elsewhere)
214
215@item
216State University of New York (SUNY) at Buffalo
217
218@item
219SunSoft, Inc. (Mountain View, California)
220
221@item
222@tex
223Technische Universit\"at M\"unchen (Munich)
224@end tex
225@ifinfo
226Technische Universitaet Muenchen (Munich)
227@end ifinfo
228
229@item
230Telecom Finland (Helsinki)
231
232@item
233Telecom Research Labs (Victoria, Australia)
234
235@item
236Union Bank of Switzerland (Zurich)
237
238@item University of Pennsylvania (Philadelphia)
239
240@item
241University of Washington (Seattle)
242
243@item
244UUNET Technologies, Inc. (Falls Church, Virginia)
245
246@item
247Warwick University (Coventry, England)
248
249@item
250Xerox Palo Alto Research Center (Palo Alto, California)
251@end itemize
252
253We are also grateful to six other organizations and individuals who
254contributed to this project, but prefer to remain anonymous.
255
256@node Versions
257@chapter Closest FSF Versions
258
259Cygnus Support devotes much of its effort to integrating and improving
260free software. In fact, Cygnus employees are the primary developers
261of several important components of the GNU tool-chain (on behalf of
262the Free Software Foundation). However, especially for programs whose
263FSF releases are issued elsewhere, our releases are often slightly
264ahead of the nearest corresponding FSF version (and sometimes slightly
265behind it). We reintegrate our sources with the FSF as frequently as
266possible without compromising the stability of the integrated
267toolchain.
268
269These are the nearest corresponding FSF releases of the GNU development
270tools:
271
272@table @sc
273@item @emph{Program}
274@emph{Last merged with FSF version}
275@item gcc
2762.0 (but many improvements from 2.1 and 2.2 incorporated)
277
278@item gdb
2794.6 (maintained at Cygnus)
280
281@end table
282
283@node New
284@chapter New in This Release
285
286@table @strong
287@item GCC
288Near command-line compatibility with the SVID specification for
289@code{cc}, and with the SVr4 @code{cc}. ELF output (with embedded
290@code{stabs} format debugging information; this is compatible with Sun's
291compilers). Many bug-fixes (from the base FSF level, and from our
292Progressive--920318 release for SunOS).
293
294@item CPP
295New directive @code{#assert}; you can use this directive, together with
296enhancements to @code{#if}, to declare and test for particular system
297properties.
298
299@item GDB
300GDB understands the debugging format used by Solaris-2 compilers (both
301ours and Sun's): @code{stabs} debugging information embedded in ELF
302object files.
303
304Since our Progressive--920318 release for SunOS, we have also made these
305improvements to GDB:
306
307Many bug fixes.
308
309GDB now uses a new memory manager called @code{mmalloc}, an enhancement
310of @sc{GNU} @code{malloc}. It can greatly speed up the startup of GDB
311by using a pre-parsed symbol table in a @code{mmalloc}-managed heap.
312Since memory-mapped files are available on Solaris-2 through the @code{mmap}
313system call, you can have GDB write the symbols from your program into a
314reusable file.
315
316@item FLEX and BYACC
317Release 1.0 for Solaris 2 includes @code{flex}, the fast lexical analyzer
318generator, and @code{byacc}, the parser generator---both from UC
319Berkeley. There are no restrictions on what use you can make of lexical
320analyzers generated by @code{flex}, or parser generators built by
321@code{byacc}.
322
323Since @code{flex} and @code{byacc} are of interest only to a specialized
324audience, we ship only on-line documentation for them.
325@inforef{Top,,flex.info}, or the @code{man} pages @samp{flex.1} and
326@samp{byacc.1}.
327
328@item Problem Reports
329The script @code{install_cid} is now available to record your Cygnus
330customer ID for the problem-reporting utility, @code{send_pr}, on your
331system.
332
333A blank Problem Report form is now included in the @cite{Introduction}
334to your Developer's Kit manuals, in case FAX is more convenient than
335electronic mail to send us problem reports.
336
337Since these programs are free software, many people who receive them
338will not get them directly from Cygnus Support. We will be glad to
339support you no matter where you got the software. If you have not yet
340bought support from Cygnus for this set of tools, you can call us at
341@w{+1 415 322 3811} for a support contract, and start reporting problems
342and getting fixes.
343@end table
344
345@node Limits
346@chapter Limitations and Warnings
347
348Our major goals in this release was compatibility: with the System V
349Interface Definition (@sc{svid}), with other Solaris-2 tools, and with
350the @sc{sparc} Application Binary Interface (@sc{abi}).
351
352We have been largely successful: our toolchain complies with the
353@sc{svid} specifications for compilation tools, most of the tools are
354also command-line compatible with the Sun offerings (even in cases where
355these go beyond the @sc{svid}), and we know of only one violation of the
356@sc{abi}.
357
358The following sections give details on the few remaining compatibility
359issues.
360
361@menu
362* gcc-options:: Some Solaris-2 cc options not accepted
363* cc-gdb:: Using gdb on Sun compiler output
364* long double:: The long double datatype violates the ABI
365* ABI:: No independent verification of ABI compliance
366@end menu
367
368@node gcc-options
369@section Some Solaris-2 @code{cc} options are not accepted
370
371In porting the @sc{gnu} C compiler to Solaris-2, we wanted to have
372command-line compatibility with several compilers:
373
374@itemize @bullet
375@item
376@sc{svid} specification for @code{cc}
377
378@item
379Other @sc{gcc} configurations
380
381@item
382Unix SVr4 implementation of @code{cc}
383
384@item
385Sun compiler for Solaris-2
386
387@end itemize
388
389@noindent
390Unfortunately, these specifications are not altogether compatible; we
391have compromised in some areas, giving the most weight to the @sc{svid}
392specification and to @sc{gcc} on other platforms.
393
394Here is a list of command line options @emph{not} accepted by
395@code{gcc}, but meaningful in one of the other command-line
396specifications listed:
397
398@table @code
399@item -Bstatic
400@itemx -Bdynamic
401Use @samp{-static} or @samp{-symbolic} instead. (@samp{-Bstatic} and
402@samp{-Bdynamic} are supported by Sun compilers, but are not in the
403@sc{svid}.)
404
405@item -dy
406@itemx -dn
407These Solaris-2 linker options conflict with @sc{gcc} debugging options.
408Again, use @samp{-symbolic} or @samp{-static} instead; or pass the
409linker options directly to the linker using @samp{-Xlinker} or
410@samp{-W}.
411
412@item -f
413@sc{gcc} has a large family of options that begin with @samp{-f}. All
414of these options are supported as in other versions of @sc{gcc}. The
415SVr4 specification describes this option as accepted, but ignored; in
416the @sc{svid}, it is used to specify floating-point emulation.
417
418@item -J sfm
419This SVr4 option appears to specify linking against a special-purpose
420subroutine library. It is not in the @sc{svid}, and @sc{gcc} does not
421support it.
422
423@item -K
424@sc{gcc} does not support @samp{-K}. To specify position-independent
425code output, use @samp{-pic}.
426
427@item -P
428This preprocessor option retains its usual @sc{gcc} meaning, which is
429slightly different from the @sc{svid} and SVr4 descriptions (which are
430not quite identical with one another). It is used to generate
431preprocessor output---similar to @samp{-E}, but without embedding
432@code{#line} directives. However, for @sc{gcc}, the output still goes
433to @file{stdout} rather than to a @samp{.i} file. To place output in a
434@samp{.i} file, use command-line output redirection.
435
436@item -q
437This option is defined as implementation-specific by the @sc{svid}.
438This implementation does not include it.
439
440@item -V
441Displays version information for @emph{only} the assembler and linker.
442
443@item -v
444Displays the full invocation of each compiler pass, as usual for
445@sc{gcc}. This option is not defined in the @sc{svid}, but the SVr4
446documentation describes it as similar to the @sc{gcc} options
447@samp{-pedantic} or @samp{-pedantic-errors}. We recommend using those
448options instead.
449
450@item -W
451@itemx -Y
452In this implementation, @samp{-W} and @samp{Y} are restricted to
453controlling the assembler and linker (the other compiler passes used by
454@sc{gcc} do not exactly correspond to those in the @sc{svid}).
455
456@item -X
457This option is not in the @sc{svid}, but is used in SVr4 to give a
458little control over the dialect of C. For this purpose, you can use the
459standard @sc{gcc} options @samp{-traditional}, @samp{-ansi}, or the
460other options described in @ref{Dialect Options,,Options Controlling
461Dialect, usegcc.info, Using gcc}.
462@end table
463
464For full descriptions of the @sc{gcc} command line options in this
465release, see the manual @cite{Using gcc}, or the man page @code{gcc.1}.
466
467@node cc-gdb
468@section Using @code{gdb} on Sun Compiler Output
469
470By default, the Sun compiler @code{cc} and the system assembler
471@code{as} omit debugging information from the final linked output file,
472assuming the debugger will look in the @samp{.o} files for this
473information. @code{gdb} will not do this. If you have the Sun compiler
474@code{cc} and want to debug its output with @code{gdb}, you must include
475the command-line flag @samp{-xs} when you run @code{cc}, to instruct it
476to place debugging information where it will be copied to the linked
477output file. Similarly, if you call the system assembler @code{as}
478directly, use its command-line option @samp{-s} for the same purpose.
479
480@node long double
481@section The @code{long double} datatype violates SPARC ABI
482
483The @sc{sparc} Application Binary Interface (@sc{abi}) specifies that
484numbers of type @code{long double} take up 16 bytes. In this release,
485@code{gcc} only emits 8-byte numbers for @code{long double}.
486
487This is the only known violation of the @sc{abi}. We will fix this
488problem in a future release.
489
490@node ABI
491@section No independent verification of ABI compliance
492
493We have made every effort to comply with the @sc{sparc} @sc{abi}, and we
494are aware of only one violation (noted above). However, there is as yet
495no independent verification of our compiler's compliance.
496
497@sc{sparc} International is preparing an ABI compliance test suite, but
498it won't be available until sometime in the autumn of 1992. We will
499seek verification of our compiler's compliance as soon as @sc{sparc}
500International is ready.
501
502@contents
503@bye
This page took 0.047715 seconds and 4 git commands to generate.