relnotes.texi

早期freebsd实现

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: [phone]
email: @code{info@@cygnus.com}

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

[phone]                            [phone]
[phone] fax                    fax [phone]
@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