\input texinfo
@c
@c This file may require a nonstandard texinfo.tex to format; if you
@c need it, please contact Cygnus Support (email editor-in-chief@cygnus.com)
@setfilename RELEASE.info
@c
@c This file describes a Cygnus Progressive Release (Developer's Kit).
@c
@c Copyright (C) 1991, 1992 Cygnus Support
@c This text may be freely distributed under the terms of the GNU
@c General Public License.
@c
@c $Id: relnotes.texi,v 1.3 1992/11/30 09:40:46 zoo Exp $
@c
@iftex
@c The include file "texiplus.tex" is in the texinfo/cygnus dir, and
@c implements Cygnus modifications to the texinfo manual style.
@input texiplus
@c The include file "smpklug.texi" is a kluge to deal with local
@c document production issues at Cygnus; it's safe to comment out this
@c line if you don't have (or don't want) the file.
@input smpklug.texi
@smallbook
@cropmarks
@finalout
@settitle Release Notes
@setchapternewpage on
@c
@end iftex
@tex
\global\def\manvers{Progressive p3-921001}
@end tex

@titlepage
@title Release Notes
@sp 3
@table @strong
@item Cygnus Support Developer's Kit
@item Progressive Release p3-921001
@end table
@author Cygnus Support
@page

@tex
\xdef\Rmanvers{{\it Release Notes (Progressive p3-921001 Developer's Kit)}} % *NOT* for use in headers, footers
{\parskip=0pt \hfill Cygnus Support\par \hfill \Rmanvers\par \hfill
\TeX{}info \texinfoversion\par }
\global\def\manvers{Progressive p3-921001}
@end tex

@vskip 0pt plus 1filll
Copyright @copyright{} 1992 Cygnus Support

Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that
the entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions.

@end titlepage

@setfilename notes-p3-921001.info
@c         PROOFREADING: set FIXMES to include FIXME text in formatted
@c         output
@clear FIXMES

@ifinfo
@node Top
@top Progressive p3-921001
@end ifinfo

@menu
* Introduction::                Overview
* Versions::                    Closest FSF Versions
* New::                         New in This Release
* Limits::                      Limitations and Warnings
* Cross::                       Cross-Development: Special Considerations
* Rebuilding::                  Rebuilding from Source
* Bugs::                        Known Bugs
* Cygnus-FSF::                  Cygnus Progressive Releases and the FSF
* Cygnus-Support::              About Cygnus Support
@end menu

@node Introduction
@chapter Overview

@table @strong
@item Cygnus Support Developer's Kit
@item Progressive Release p3-921001
@end table

This is the first Progressive Release where several standard
@dfn{cross-development} configurations are available.  A
cross-development configuration is for developing software to run on a
different machine (the @dfn{target}) than the development tools
themselves (which run on the @dfn{host})---for example, you might use a
SPARCstation to generate and debug code for an AMD 29K-based board.

Naturally, we also continue to offer @dfn{native} configurations, where
the tools and your code run on the same kind of machine.

This table shows the host/target combinations available:

@ifinfo
@example
       \ HOST |                   DEC   IBM   SGI
TARGET  \     | SUN3  SUN4  SOL2  STN   RS6K  IRIS  DOS  HP300  HP700
--------------+--------------------------------------------------------
Native        |  X     X     X     X     X     X     
68k VxWorks   |  X     X           X     X     X           X      X
68k a.out     |  X     X           X                 X            X
68k coff      |        X           O                 O
29k UDI       |        X                             X
ix86 a.out    |        X           O                 O
i960 VxWorks  |        O           O     X                        O
i960 Nindy    |        O           O
SPARC VxWorks |        X                                               
SPARC a.out   |        O            

X     = on the shelf                     
O     = may be custom built
68k   = 68000, 68010, 68020, 68030, 68040
ix86  = 386, 486
i960  = KA, KB, CA
SPARC = SPARC, SPARClite
@end example
@end ifinfo

@tex
{\def\X{\vrule height 0.4em width0.4em}
\halign{\hfill \rm #\ &\bf\hfil # \hfil\ &\bf\hfil # \hfil\ &\bf\hfil #
\hfil\ &\bf\hfil # \hfil\ &\bf\hfil # \hfil\ &\bf\hfil #
\hfil\ &\bf\hfil # \hfil\ &\bf\hfil # \hfil\ & \bf\hfil # \hfil\cr
\cr
          &Sun  &Sun  &Sol  &DEC    &IBM &SGI &   &HP    &HP\cr
\bf TARGET&3    &4    &2    &stn    &rs6k&Iris&DOS&300   &700   \cr
\noalign{\strut\hrule}
\noalign{\strut}
\it Native&\X  &\X  &\X  &\X    &\X &\X \cr
68k VxWorks&\X  &\X  &     &\X    &\X &\X &   & \X  & \X  \cr
68k a.out &\X  &\X  &     &\X    &    &    &\X&      & \X  \cr
68k coff  &     &\X  &     &\ *   &    &    &\ *&      &      \cr
29k UDI   &     &\X  &     &       &    &    &\X&      &      \cr
iX86 a.out&     &\X  &     &\ *   &    &    &\ *&      &      \cr
i960 VxWorks&   &\ * &     &\ *   &\X &    &   &      &\ *  \cr
i960 Nindy&     &\ * &     &\ *   &    &    &   &      &      \cr
SPARC VxWorks&  &\X  &     &       &    &    &   &      &      \cr
SPARC a.out&    &\ * &     &       &    &    &   &      &      \cr
\cr}
\halign{\rm\hfil #\quad$=$\quad&\rm #\hfil\cr
\X&on the shelf\cr
\ *&custom tape\cr
\cr
68k&Motorola 68000, 68010, 68020, 68030, 68040\cr
iX86&Intel 386, 486\cr
i960&Intel 960 KA, KB, CA\cr
SPARC&SPARC, SPARClite\cr
\cr}}
@end tex

Your tape is labeled with @samp{host=@var{platform}} to indicate the
host for that configuration.  To avoid ambiguity, these names use a
three-part naming scheme which identifies the CPU, vendor, and
operating system:

@table @r
@item Sun-3
@code{m68k-sun-sunos411}

@item Sun-4
@code{sparc-sun-sunos411}

@item Solaris 2
@code{sparc-sun-solaris2}

@item DECstation
@code{mips-dec-ultrix}

@item SGI Iris
@code{mips-sgi-irix4}

@item IBM RS6000
@code{rs6000-ibm-aix}

@item HP-700
@code{hppa1.1-hp-hpux}

@item HP-300
@code{m68k-hp-hpux}

@item DOS
@code{i386-gen-dos}
@end table

If you have a cross development tape, the label also indicates
@samp{target=@var{machine}} to identify the target for that
configuration.  A two-part naming scheme identifies CPU and object code
format or cross-development environment:

@table @r
@item Motorola 680x0 family
@code{m68k-aout}---a.out object code format.
@code{m68k-coff}---coff object code format.
@code{m68k-vxworks}---VxWorks environment.

@item Intel 960 family
@code{i960-vxworks}---VxWorks environment.
@code{i960-nindy}---Nindy monitor.

@item AMD 29000 family
@code{a29k-amd-udi}---UDI monitor interface.  (To use the MINIMON
interface, use this configuration with the program @code{MONTIP},
available from AMD at no charge.)

@item SPARC family
@code{sparc-vxworks}---VxWorks environment.
@code{sparc-aout}---a.out object code format.

@item Intel 386 family
@code{i386-aout}---a.out object code format.
@end table

In cross-development configurations, each tool in the Developer's Kit is
named with the identifying string as a prefix.  For example, if the C
compiler is configured to generate COFF format code for the Motorola
680x0 family, the compiler is installed as @file{m68k-coff-gcc}.

@node Versions
@chapter Closest FSF Versions

Cygnus Support devotes much of its effort to integrating and improving
free software.  In fact, Cygnus employees are the primary developers of
several important components of the GNU tool-chain (on behalf of the
Free Software Foundation).  However, for programs whose FSF releases are
issued elsewhere, our releases are often slightly ahead of the nearest
corresponding FSF version.  We reintegrate our sources with the FSF as
frequently as possible without compromising the stability of the
integrated toolchain.

These are the closest corresponding FSF releases of the GNU development
tools:

@table @sc
@item @emph{Program}
@emph{Closest FSF version}
@item gcc/g++
pre-2.3

@item gdb
4.6.5 (maintained at Cygnus)

@item make
3.62.16 (not supplied for DOS hosts)

@item libg++
2.2.2 (maintained at Cygnus)
@end table

For all cross-development configurations, and on Sun-4 (other than
Solaris-2) and Sun-3 native configurations, these supporting programs
are also included:

@table @sc
@item as
1.91

@item ld
1.97.1 (maintained at Cygnus)

@item Binary Utilities
1.97 (maintained at Cygnus)
@end table

@sp 4
A Progressive Release of @sc{gnu} Emacs is also available
separately from Cygnus Support for selected hosts.

@node New
@chapter New in This Release

@table @strong
@item Cross-Development
The focus on cross development in release p3-921001 makes standard
support available for the first time for many embedded systems
applications.  The additional testing, configuration, and cleanup work
required has also made the native configurations even more robust.

@item New Hosts
There is a new native configuration, the Solaris-2 environment (SunOS
5.0), and three new hosts for cross-development only---HP-300, HP-700,
and DOS.

@item C library
We have assembled, improved, and documented a standard C subroutine library
@file{libc.a} and C mathematical subroutine library @file{libm.a}.
These are @emph{not} GNU libraries, so there are no additional
code distribution requirements for programs that use them.

@item C++
@code{g++} and @code{libg++} continue to grow more robust.  You can 
compile many popular applications and class libraries with GNU C++,
including @code{groff} and Rogue Wave.

This release of @code{g++} is still unable to build the entire NIHCL and
InterViews libraries, but the @code{g++} renovation project (underway)
will address these incompatibilities.

@item GDB symbol quoting and completion
The GNU debugger will interactively help you select among similar (or
overloaded) names, with extensions to its command-line completion
facilities to apply completion to symbols, and to allow you to quote
symbols in order to alter the scope of completion.
@end table

@node Limits
@chapter Limitations and Warnings

In this release, some of the supported systems don't run some of the
supporting GNU programs, and one system (the RS/6000) has a number of
special requirements.

@menu
* remove::                      Install remove may go too far
* unavailable::                 Programs not available
* rs6000::                      RS/6000 special requirements
@end menu

@node remove
@section @code{Install remove} may go too far

The @code{Install} script that comes with your Developer's Kit release
can also be used to remove either the source, or the binaries, after
installation.  However, in this release, @samp{Install remove} is not
selective enough.  If you install more than one configuration of the
release in the same directory (for example, under the default directory
@file{/usr/cygnus}), @samp{./Install remove} will delete
@emph{all} installed configurations; there is no way
to select just files from one or another package.

We will rectify this problem in future releases.


@node unavailable
@section Programs not Available
Progressive p3-921001 does @emph{not} include the following
supporting programs on the native configurations for Solaris-2, Iris,
DECstation, or RS/6000.  You must use the native equivalents, supplied
by the machine vendors, with the @sc{gnu} compiler:

@table @r
@item @sc{as}
assembler

@item @sc{ld}
linker

@item Binary Utilities
@code{ar}, @code{nm}, @code{objdump},
@code{ranlib}, @code{size}, @code{strip}
@end table

@node rs6000
@section RS/6000 Assembler Upgrades

Debugging code compiled with @sc{gcc} on the RS/6000 requires that you
upgrade the AIX assembler @code{/bin/as} with a replacement that is available
from IBM.  Without the upgrade, you can still compile your code, but
@samp{gcc -g @dots{}} will not work.

Any IBM RS/6000 customer can order and get the replacement assembler,
and install it on one or more machines.  It is distributed both on
diskette and via VNET, for downloading via ftp.  VNET distribution may
be desirable if you have a friendly IBM representative nearby with a
networked VM machine.

In either case, to order the replacement assembler from IBM, first
execute @samp{lslpp -h bos.obj} to determine your release level.  (Look
on the @samp{ACTIVE} line for something like @samp{03.01.0005.0012}.)
Then (in North America) call IBM Support at 800--237--5511.  Ask for
emergency shipment of the RS/6000 AIX fix for APAR IX26107.  They may
ask you to verify that it's a fix for ``Don't allow @code{.csect
name[BS]} or @code{[UC]}''; say yes.  They may also ask you for your
customer number.  If you do not know it, you will still be able to get
the fix, but you will have to be persistent.

You will receive a tar or tar.Z file containing an assembler plus
installation instructions.

If you tell them you're running AIX version 3.2, you may be told that
no fix is available yet.  In fact the 3.1.5 fix works fine on version
3.2.  Request it anyway.

IBM has corresponding support organizations outside of North America.
If you are not in North America, call your IBM branch office and ask
them to put you in touch with the department that handles emergency
fixes for AIX on the RS/6000.  If that doesn't work, ask for the
department that handles software defect support for AIX on the RS/6000.
Then ask for the emergency APAR fix.

@node Cross
@chapter Cross-Development: Special Considerations

Using the Developer's Kit in one of the cross-development configurations
may require more attention to two areas.  (A cross-development
configuration is for developing software to run on a different machine
than the development tools themselves.)

First, as a prerequisite to development, you may need to set up the
target environment.  Second, if you use LIBG++ (the GNU C++ class
libraries), you may want to consider special licensing terms from the
FSF for your product.

@menu
* Target setup::     Setting up the target environment
* Licensing::        LIBG++ licensing terms
@end menu

@node Target setup
@section Setting up the target environment

To allow our tools to work with your target environment (except for
VxWorks, which provides full operating system support), you need to set
up:

@itemize @bullet
@item
the C run-time environment (described below).

@item
stubs or minimal versions of operating-system subroutines for the C
subroutine library.  @xref{syscalls,,System Calls,libc.info, The Cygnus
C Support Library}.

@item
a connection to the debugger.  @xref{Remote,,Remote Debugging,gdb.info,
Debugging with GDB}.
@end itemize

@subheading The C Run-Time Environment (@code{crt0})

To link and run C or C++ programs, you need to define a small
module (usually written in assembler as @file{crt0.s}) that makes sure
the hardware is initialized for C conventions before calling
@code{main}.

You will need this information about your target:

@itemize --
@item
A memory map.  What memory is available, and where?  

@item
Which way does the stack grow?

@item
What output format will you use?
@end itemize

At a minimum, your @code{crt0} must do these things:

@enumerate 1
@item
Define the symbol @code{start} (@samp{_start} in assembler code).
Execution will begin at this symbol.

@item
Set up the stack pointer @code{sp}.  It is largely up to you to choose
where to store your stack within the constraints of your target's memory
map.  Perhaps the simplest choice is to choose a fixed-size area
somewhere in the uninitialized-data (@samp{bss}) section.  Remember that
whether you choose the low address or the high address in this area
depends on the direction your stack will grow.

@item
Initialize all memory in the uninitialized-data (@samp{bss}) section to
zero.  The easiest way to do this is with the help of a linker script
(@pxref{Commands,,Command Language,ld.info, Using LD, the GNU linker}).
Use a linker script to define symbols such as @code{bss_start} and
@code{bss_end} to record the boundaries of this section; then you can
simply loop between them in @code{crt0}.

@item
Call @code{main}.  Nothing else will!
@end enumerate

@noindent
A more complete @code{crt0} might also do the following:

@enumerate 5
@item
Define an @code{_exit} subroutine (this is the C name; in your assembler
code, use the label @code{__exit}).  Its precise behavior will depend on
the details of your system---and on your choice.  Possibilities include
trapping back to the boot monitor, if there is one; or to the loader, if
there is no monitor; or even back to @code{start}.

@item
If your target has no monitor to mediate communications with the
debugger, @code{crt0} is where you must set up the hardware exception
handler.  @xref{Remote Serial,,The GDB remote serial protocol,gdb.info,
Debugging with GDB}, for details on how to use GDB's generic
remote-target facilities for this purpose.

@item
Perform other hardware-dependent initialization; for example,
initializing an MMU or an auxiliary floating-point chip.

@item
On some systems, copy microcode from ROM to RAM; see your target
manufacturer's hardware manual if you're not certain whether this is
needed.

@item
Define low-level input and output subroutines.  For example, @code{crt0}
is a convenient place to define the minimal assembly-level routines
described in @ref{syscalls,,System Calls,libc.info, The Cygnus C Support
Library}.
@end enumerate

@node Licensing
@section LIBG++ licensing terms

LIBG++ is licensed under the GNU Library General Public License (LGPL); for
embedded-system developers who use this library, the automatically
available terms defined there may be inconvenient.  (This issue does
@emph{not} arise for the C subroutine libraries in cross-development
configurations of the Cygnus Developer's Kit.  The C subroutine
libraries are not LGPL libraries---Cygnus has developed them or assembled
them from sources that require only copyright acknowledgement.)

The GNU Library General Public License is designed to promote
software sharing among computer users.  As a consequence, its terms
require that you make the source code for the library available with
any program you distribute that uses a GNU library, and that you allow
users of your programs to relink them with modified or updated copies
of the library.

These terms work well for programs that run on general-purpose
computer systems.  But they may be impractical for programs in embedded
systems, where the end user may not even be aware that computers and
programs are involved in a product.

The Free Software Foundation (FSF) is aware of this problem, and has
expressed willingness to grant permission for library use in embedded
systems under alternative licensing terms.  However, the LGPL is the
only license that is automatically available; to arrange for alternative
terms for your embedded application, you must contact the FSF directly.
Write to

@display
Free Software Foundation, Inc.
675 Mass Ave.
Cambridge, MA   
USA        02139
@end display

You can also send electronic mail to @samp{gnu@@gnu.ai.mit.edu}.

The Foundation will want to know enough about your application to
ensure that the ordinary LGPL terms do not make sense in your case,
and that your intended use does not contravene the goals of promoting
software sharing, and of preserving the free status of all derivatives
of GNU software.  You can save time by making certain you supply this
information in your initial letter.

For example, you can use a letter of this form, signed by an
authorized officer of your organization:

@quotation
1 April 2002

Dear FSF Staff:

Our company, SmallZap Inc., builds intelligent electronic flea traps.
Our product plans call for use of the GNU C++ Library (LIBG++) in
writing the software for the embedded controller.

Our market research indicates that serving our customers' immediate
needs requires a device with the simplest possible controls.
Therefore, the device cannot be reprogrammed, and it would be
impractical, confusing, and pointless to supply source code for this
Library, or to supply a relinkable form of our own code.

Accordingly, we request permission from the FSF to distribute devices
that use programs linked with the Library without meeting these two
requirements of the GNU Library General Public License (LGPL).

SmallZap Inc. acknowledges that this permission is not transferrable
to any other organization or individual.

SmallZap Inc. hereby certifies that we will meet the full LGPL terms
in any software distributions intended for general-purpose computers,
or with any product where the programs are on rewritable media.

SmallZap Inc. hereby acknowledges that there is NO WARRANTY for GNU
Libraries, and assumes all liability for its use of GNU Library code
in our embedded controllers.

The undersigned is an authorized representative of SmallZap Inc.

yours,

@display
@var{authorized signature}
S. M. Zap
Debugging Officer
SmallZap Inc.
@end display
@end quotation

@node Rebuilding
@chapter Rebuilding From Source

All Cygnus products are free software; your Developer's Kit includes
complete source code for all programs.

Cygnus Support has implemented an automatic configuration scheme to
adapt the programs to different environments.

Rebuilding the programs from source requires these steps:
@enumerate
@item
configuration
@item
compilation
@item
installation
@end enumerate

For example, executing the following commands in sequence will rebuild
and install a Sun-4 native version of all the tools in a nonstandard
directory:

@c FIXME! need to add stuff about -suffix or some such

@cartouche
@example
eg$ @b{cd p3-921001/src}

eg$ @b{./configure sun4 -prefix=/local/gnu}
Created "Makefile" in @var{installdir}/p3-921001/src

eg$ @b{make clean all info install install-info >make.log}
@dots{} @i{output for @code{make} steps follows}
@end example
@end cartouche

@noindent
We discuss each step in detail in the following sections.

@menu
* Configuration::               Configuration
* Config Names::                Specifying Names for Hosts and Targets
* configure Options::           @code{configure} Options
* Compilation::                 Compilation
* Installation::                Installation
@end menu

@node Configuration
@section Configuration

You can configure the software in this release by using the shell
script called @code{configure}.  The shell script requires one argument:
the host type.  There are also several possible options, including a
@samp{-target=} option to configure for cross-system development.

@node Config Names
@section Specifying Names for Hosts and Targets

The specifications used for hosts and targets in the @code{configure}
script are based on a three-part naming scheme, but some short predefined
aliases are also supported.  The full naming scheme encodes three pieces
of information in the following pattern:

@example
@var{architecture}-@var{vendor}-@var{os}
@end example

For example, you can use the alias @code{sun4} as a @var{host} argument
or in a @samp{-target=@var{target}} option, but the equivalent full name
is @samp{sparc-sun-sunos4}.

@quotation
@emph{Warning:} @code{configure} can represent a very large number of
combinations of architecture, vendor, and OS.  There is by no means
support for all possible combinations!
@end quotation

@node configure Options
@section @code{configure} Options

This section summarizes the @code{configure} options and arguments.
Your Developer's Kit contains full online documentation for the Cygnus
configure system.  @inforef{Using Configure,,configure.info}, to read
about @code{configure} in more detail, including information on how the
@code{configure} options relate to @file{Makefile} variables.

@example
configure @r{[}-prefix=@var{dest}@r{]} 
          @r{[}-exec-prefix=@var{bindest}@r{]} 
          @r{[}-srcdir=@var{path}@r{]}
          @r{[}-norecursion@r{]} 
          @r{[}-target=@var{target}@r{]}
          @var{host}
@end example

@table @code
@item -prefix=@var{dest}
@var{dest} is an installation directory @emph{path prefix}, the root for
the directories where @code{make install} will place things.  After you
configure with this option, @samp{make install install-info} will
install info files in @file{@var{dest}/info}, man pages in
@file{@var{dest}/man}, and---unless you also use
@samp{-exec-prefix}---compiled programs in @file{@var{dest}/bin}, and
libraries in @file{@var{dest}/lib}.  If you specify
@samp{-prefix=/local}, for example, @code{make install} puts the
development tools in @file{/local/bin}.

@emph{WARNING:} the default @var{dest} path prefix in the source is not
the same as the prefix for the preconfigured binaries distributed by
Cygnus.  If you do not use @code{-prefix}, the installation directory is
@file{/usr/local}.

@item -exec-prefix=@var{bindest}
@samp{-exec-prefix} serves the same purpose as @samp{-prefix}, but
affects only machine-dependent targets (compiled programs and
libraries).  Specifying both @samp{-prefix} and @samp{-exec-prefix}
allows you to segregate machine-dependent files, so that
machine-independent files can be shared.  

@emph{WARNING:} the default @var{bindest} path prefix in the source is not
the same as the prefix for the preconfigured binaries distributed by Cygnus.
If you do not use @samp{-exec-prefix}, the default directory for
machine-dependent targets is whatever was specified with @file{-prefix}
(by default, @file{/usr/local}).

@item -srcdir=@var{path}
@emph{Warning: This option is only supported if you use @sc{gnu}
@code{make}} (which is included in the release, except for DOS hosts).
Use this option to make configurations in directories separate from the
source directories. @code{configure} writes configuration specific files
in the current directory, but arranges for them to use the source in the
directory @var{path}.  @code{configure} will create directories under
the working directory in parallel to the source directories below
@var{path}.  Among other things, you can use this to build (or maintain)
several configurations simultaneously, in separate directories.

@item -norecursion
Configure only the directory level where @code{configure} is executed; do not
propagate configuration to subdirectories.

@item -target=@var{target}
Configure the development tools for cross-development (compiling,
debugging, or other processing) of programs running on the specified
@var{target}.  Without this option, programs are configured ``native'',
that is, for managing programs that run on the same machine (@var{host})
as the development tools themselves.

There is no convenient way to generate a list of all available targets.

@item @var{host} @dots{}
Configure the development tools to run on the specified @var{host}.

There is no convenient way to generate a list of all available hosts.
@end table

The @samp{-prefix=@var{dest}} and @samp{-exec-prefix=@var{bindest}}
options are particularly important.  If you don't specify a @var{dest}
or @var{bindest} directory, the @file{Makefile} installs binaries in
subdirectories of @file{/usr/local}.  These options are important
because the @var{dest} and @var{bindest} directories are used for
several purposes:

@enumerate
@item
@var{bindest} is the directory where binaries are installed.

@item
@var{bindest} is built into the compiler itself for the
locations of @sc{gcc} specific include files, the locations of @sc{gcc}
subprograms, and the location of the @sc{gcc} specific library
@file{libgcc.a}.

@item
@var{dest} is compiled into @code{info} as the default directory
for the documentation.

@end enumerate

@node Compilation
@section Compilation

After you've run @code{configure} (which writes the final
@file{Makefile} in each directory), compilation is straightforward.
To compile all the programs in the Developer's Kit, run:

@cartouche
@example
@b{make all info >make.log}
@end example
@end cartouche

The examples suggest capturing the @code{make} output in a
@file{make.log} file, because the output is lengthy.  

The overall @file{Makefile} propagates the value of the @code{CC}
variable explicitly, so that you can easily control the compiler used in
this step.  @code{CFLAGS} is treated the same way.  For instance, to
build the compiler a second time, using @sc{gcc} to compile itself
(after building and installing it in the alternate directory
@file{/local/gnu}), you might use

@cartouche
@example
@b{make CC=/local/gnu/H-sun4/bin/gcc CFLAGS=-O all info  >make.log}
@end example
@end cartouche

The conventional targets @samp{all}, @samp{install}, and @samp{clean}
are supported at all levels of @file{Makefile}.  Other targets are
supported as well, as appropriate in each directory; please read the
individual @file{Makefile} for details.  Each @file{Makefile} in the
source directories includes ample comments to help you read it.  If you
are not familiar with @code{make}, refer to @ref{Overview,,Overview of
@code{make}, make.info, GNU Make: A Program for Directing
Recompilation}.

@node Installation
@section Installation

Whether you configure an alternative path using @code{-prefix}, or you
use the default installation path @file{/usr/local}, you can install the
software by executing:

@cartouche
@example
@b{make install install-info}
@end example
@end cartouche

@node Bugs
@chapter Known Bugs

Attached at the end of this document is a listing of the
known bugs in the Progressive p3-921001 release.  These are organized 
by software category, for example, 
@code{g++}, or @code{gdb}.

Each bug summary begins with the Cygnus PR number and the current state
of the problem report.  We consider a problem report @dfn{closed} only when
the customer who reported the bug agrees the problem is solved.
(Closed bugs are not shown in these summaries.)

The state shown in each problem summary is one of:

@table @r
@item open
We have not yet investigated this bug.

@item analyzed
We have examined the situation and diagnosed the problem; a bug fix is
pending. 

@item suspended
We have examined the situation and diagnosed the problem, but determined
that a fix cannot currently be applied.  

@item feedback
We have applied a fix, but have not yet received confirmation from the
customer that this solves the problem.  Also indicates bugs awaiting
more information from the customer.

@end table



@node Cygnus-FSF
@chapter Cygnus Releases and the FSF

Most of the tools in this Developer's Kit are originally from the Free
Software Foundation (FSF).  You can get versions of all these tools
from the FSF as well as from Cygnus.  In general, Cygnus Progressive
Releases add to FSF software in the following ways:
@c UPDATE! more differences bet Cygnus/FSF releases?

@itemize @bullet
@item
Commercial support is available.  Cygnus adds value to FSF releases in
large measure by offering outstanding support services.
@item
Coordination.  The tools in your Developer's Kit are certified to work
together; you need not worry about tools being out of step with each other.
@item
Bug fixes.  A Progressive Release includes many fixes, already integrated
into the programs.  Cygnus repairs bugs discovered during testing, and
also tracks and includes bug fixes developed for other Cygnus customers
or distributed over the Internet.
@item
Bug reporting.  Cygnus releases include the tool @code{send_pr}, which
you can use to make sure your problem reports receive prompt attention,
and are also incorporated in our future tests.
@item
Documentation.  Cygnus revises and adds to available FSF
documentation to give you better descriptions of all the software tools.
@item
Stability.  Cygnus tests (and uses) all the programs it releases.
@end itemize

@node Cygnus-Support
@chapter About Cygnus Support

Cygnus Support was founded in 1989 to provide commercial support for
free software.  Cygnus supplies products and services that benefit
advanced development groups by allowing them to use state-of-the-art
tools without having to maintain them.  With Cygnus Support, sites that
once were forced to do their own tool support can recover that valuable
staff time.  Former users of proprietary software now may choose
supported free software, combining the advantages of both worlds.

Free software is faster, more powerful, and more portable than its
proprietary counterparts.  It evolves faster because users who want to
make improvements are free to do so.  Cygnus tracks these
improvements and integrates them into tested, stable versions ready
for commercial use, then backs this software with comprehensive
support.

With Cygnus Support as your partner, you will have the software and
the support you need to meet your business objectives.  Cygnus
is intimately familiar with this software from extensive experience
using, debugging, and implementing it.  You get direct access to the
most qualified support people: the authors of the software.

We provide ``vintage'' releases---the most stable versions, which have
been though even more extensive use and testing---or up-to-the minute
``progressive'' releases, for those who need the very latest version.

Because all our improvements are also free software, you can
distribute them widely within your organization, or to your customers,
without extra cost.

@sp 4

@ifinfo
@display
Cygnus Support
hotline: +1 415 903 1401
email: @code{info@@cygnus.com}

HEADQUARTERS                                    EAST COAST
1937 Landings Drive                     One Kendall Square
Mountain View, CA 94043 USA            Cambridge, MA 02139

+1 415 903 1400                            +1 617 494 1040
+1 415 903 0122 fax                    fax +1 617 494 1325
@end display
@end ifinfo

@tex
\halign{\rm #\hfill&\rm\qquad\qquad\hfill #\cr
\bf Cygnus Support\cr
hotline: $+$1 415 903 1401\cr
email: @code{info@@cygnus.com}\cr
\cr
\it Headquarters       &\it East Coast\cr
1937 Landings Drive             &        One Kendall Square\cr
Mountains View, CA 94043 USA    &       Cambridge, MA 02139\cr
\cr
$+$1 415 903 1400               &            $+$1 617 494 1040\cr
$+$1 415 903 0122 fax           &        fax $+$1 617 494 1325\cr}
@end tex

@contents
@bye
