RTOS/rtems
1
0
Fork 0
forked from Imagelibrary/rtems
Code Pull Requests Activity

2002-11-13 Joel Sherrill <joel@OARcorp.com>

Browse Source 
* Makefile.am, buildc.t, buildrt.t, nt.t, require.t, tversions.texi:
	Removed all references to bit scripts.
	* gdb.t: Removed.
This commit is contained in:
Joel Sherrill
2002-11-13 20:20:29 +00:00
parent 5a951c9d17
commit 4a675a5c59
8 changed files with 37 additions and 716 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/started/ChangeLog
View File

@@ -1,3 +1,9 @@
2002-11-13 Joel Sherrill <joel@OARcorp.com>
* Makefile.am, buildc.t, buildrt.t, nt.t, require.t, tversions.texi:
Removed all references to bit scripts.
* gdb.t: Removed.
2002-11-13 Joel Sherrill <joel@OARcorp.com>
* stamp-vti, version.texi: Regenerated.

4
doc/started/Makefile.am
View File

@@ -52,7 +52,7 @@ $(srcdir)/buildrt.texi: buildrt.t tversions.texi
-n "Building the Sample Application" < $< > $@
$(srcdir)/sample.texi: sample.t tversions.texi
$(BMENU2) -c -p "Using the bit_rtems Script" \
$(BMENU2) -c -p "Using the RTEMS configure Script Directly" \
-u "Top" \
-n "Where To Go From Here" < $< > $@
@@ -66,5 +66,5 @@ $(srcdir)/nt.texi: nt.t tversions.texi
-u "Top" \
-n "" < $< > $@
EXTRA_DIST = binaries.t buildc.t buildrt.t gdb.t intro.t nextstep.t nt.t \
EXTRA_DIST = binaries.t buildc.t buildrt.t intro.t nextstep.t nt.t \
require.t sample.t

298
doc/started/buildc.t
View File

@@ -115,8 +115,8 @@ of each component as well as any required RTEMS specific patches.
@subsection Unarchiving the Tools
NOTE: This step is required if building BINUTILS, GCC, and NEWLIB
using the procedures described in @ref{Using configure and make}
or @ref{Using the bit Script}. It is @b{NOT} required if using the procedure
using the procedure described in @ref{Using configure and make}.
It is @b{NOT} required if using the procedure
described in @ref{Using RPM to Build BINUTILS GCC and NEWLIB}.
GNU source distributions are archived using @code{tar} and
@@ -169,12 +169,6 @@ The tree should look something like the following figure:
@end group
@end example
@c @ifset use-html
@c @html
@c <IMG SRC="bit_c.jpg" WIDTH=816 HEIGHT=267 ALT="Directory Organization">
@c @end html
@c @end ifset
@c
@c Applying RTEMS Patches
@c
@@ -182,8 +176,8 @@ The tree should look something like the following figure:
@subsection Applying RTEMS Patches
NOTE: This step is required if building BINUTILS, GCC, and NEWLIB
using the procedures described in @ref{Using configure and make}
or @ref{Using the bit Script}. It is @b{NOT} required if using the procedure
using the procedures described in @ref{Using configure and make}.
It is @b{NOT} required if using the procedure
described in @ref{Using RPM to Build BINUTILS GCC and NEWLIB}.
This section describes the process of applying the RTEMS patches
@@ -297,12 +291,12 @@ This should not happen with a good patch file which is properly applied.
@subsection Compiling and Installing BINUTILS GCC and NEWLIB
There are three methods to compile and install BINUTILS, GCC, and NEWLIB:
There are two supported methods to compile and install BINUTILS, GCC,
and NEWLIB:
@itemize @bullet
@item RPM
@item direct invocation of @code{configure} and @code{make}
@item using the @code{bit} script
@end itemize
Direct invocation of @code{configure} and @code{make} provides more control
@@ -543,248 +537,6 @@ refer to the documentation for @value{GCC-UNTAR} or
invoke the @value{GCC-UNTAR} @code{configure} command with the
@code{--help} option.
@c
@c Using the bit Script
@c
@subsubsection Using the bit Script
NOTE: The procedures described in the following sections must
be completed before this step:
@itemize @bullet
@item @ref{Obtain Source and Patches for BINUTILS GCC and NEWLIB}
@item @ref{Unarchiving the Tools}
@item @ref{Applying RTEMS Patches}
@end itemize
This section describes the process of building using the
@code{bit} script. This script hides many of the details
of building the tools but can be a hindrance if you
encounter problems building the tools.
@c
@c Unarchiving the Build Scripts
@c
@subheading Unarchiving the Build Scripts
While in the @code{tools} directory, unpack the compressed
tar file for the build tools using the following command sequence:
@example
cd tools
tar xzf ../archive/@value{BUILDTOOLS-TAR}
@end example
After the compressed tar file @value{BUILDTOOLS-TAR} has been unpacked, there
will be a set of scripts in the tools directory along with
any source code you have previously unarchived.
These scripts are intended to aid in building the tools and RTEMS.
These scripts may be used to automate the tool building process and hide
the invocation of @code{configure} and @code{make} from you. They are:
@itemize @bullet
@item bit
@item bit_gdb
@item bit_rtems
@item common.sh
@item user.cfg
@end itemize
If @code{bit} is executed later in this process,
it will automatically create this subdirectory:
@itemize @bullet
@item build-$@{CPU@}-tools
@end itemize
At this point, the tree should look something like the following figure:
@example
@group
/whatever/prefix/you/choose/
archive/
@value{GCC-TAR}
@value{BINUTILS-TAR}
@value{NEWLIB-TAR}
@value{BUILDTOOLS-TAR}
@ifset GCC-RTEMSPATCH
@value{GCC-RTEMSPATCH}
@end ifset
@ifset BINUTILS-RTEMSPATCH
@value{BINUTILS-RTEMSPATCH}
@end ifset
@ifset NEWLIB-RTEMSPATCH
@value{NEWLIB-RTEMSPATCH}
@end ifset
tools/
@value{BINUTILS-UNTAR}/
@value{GCC-UNTAR}/
@value{NEWLIB-UNTAR}/
bit
bit_gdb
bit_rtems
common.sh
user.cfg
@end group
@end example
@c @ifset use-html
@c @html
@c <IMG SRC="bit_c.jpg" WIDTH=816 HEIGHT=267 ALT="Directory Organization">
@c @end html
@c @end ifset
@c
@c Localizing the Configuration
@c
@subheading Localizing the Configuration
Edit the @code{user.cfg} file to alter the settings of various
variables which are used to tailor the build process.
Each of the variables set in @code{user.cfg} may be modified
as described below:
@table @code
@item INSTALL_POINT
is the location where you wish the GNU C/C++ cross compilation tools for
RTEMS to be built. It is recommended that the directory chosen to receive
these tools be named so that it is clear from which gcc distribution it
was generated and for which target system the tools are to produce code for.
@b{WARNING}: The @code{INSTALL_POINT} should not be a subdirectory
under the build directory. The build directory will be removed
automatically upon successful completion of the build procedure.
@item BINUTILS
is the directory under tools that contains @value{BINUTILS-UNTAR}.
For example:
@example
BINUTILS=@value{BINUTILS-UNTAR}
@end example
@item GCC
is the directory under tools that contains @value{GCC-UNTAR}.
For example,
@example
GCC=@value{GCC-UNTAR}
@end example
@item GDB
is the directory under tools that contains @value{GDB-UNTAR}.
For example,
@example
GDB=@value{GDB-UNTAR}
@end example
@item NEWLIB
is the directory under tools that contains @value{NEWLIB-UNTAR}.
For example:
@example
NEWLIB=@value{NEWLIB-UNTAR}
@end example
@item BUILD_DOCS
is set to "yes" if you want to install documentation. This requires
that tools supporting documentation production be installed. This
currently is limited to the GNU texinfo package.
For example:
@example
BUILD_DOCS=yes
@end example
@item BUILD_OTHER_LANGUAGES
is set to "yes" if you want to build languages other than C and C++. At
the current time, the set of alternative languages includes Java, Fortran,
and Objective-C. These alternative languages do not always build cross.
Hence this option defaults to "no".
For example:
@example
BUILD_OTHER_LANGUAGES=yes
@end example
@b{NOTE:} Based upon the version of the compiler being used, it may not
be possible to build languages other than C and C++ cross. In many cases,
the language run-time support libraries are not "multilib'ed". Thus the
executable code in these libraries will be for the default compiler settings
and not necessarily be correct for your CPU model.
@end table
The other variables in @code{user.cfg} are RTEMS specific and are
not technically required to be set unless you build RTEMS using
the @code{bit_rtems} script as described in
@ref{Using the bit_rtems Script}. They are described in detail
in that section.
@c
@c Running the bit Script
@c
@subheading Running the bit Script
After the @code{bit} script has been modified to reflect the
local installation, the modified @code{bit} script is run
using the following sequence:
@example
cd tools
./bit <target configuration>
@end example
Where <target configuration> is one of the following:
@itemize @bullet
@item hppa1.1
@item i386
@item i386-coff
@item i386-elf
@item i960
@item m68k
@item m68k-coff
@item mips64orion
@item powerpc
@item sh
@item sh-elf
@item sparc
@end itemize
The build process can take a while to complete. Many users find it
handy to run the build process in the background, capture the output
in a file, and monitor the output. This can be done as follows:
@example
./bit <target configuration> >bit.log 2>&1 &
tail -f bit.log
@end example
If no errors are encountered, the @code{bit} script will conclude by
printing messages similar to the following:
@example
The build-i386-tools subdirectory may now be removed.
Started: Fri Apr 10 10:14:07 CDT 1998
Finished: Fri Apr 10 12:01:33 CDT 1998
@end example
If the @code{bit} script successfully completes, then the
GNU C/C++ cross compilation tools are installed.
If the @code{bit} script does not successfully complete, then investigation
will be required to determine the source of the error.
@c -------------------
@c
@c Building the GNU Debugger GDB
@c
@@ -919,7 +671,6 @@ There are three methods of building the GNU Debugger:
@itemize @bullet
@item RPM
@item direct invocation of @code{configure} and @code{make}
@item using the @code{bit_gdb} script
@end itemize
Direct invocation of @code{configure} and @code{make} provides more control
@@ -1044,43 +795,6 @@ refer to the documentation for @value{GDB-UNTAR} or
invoke the @value{GDB-UNTAR} @code{configure} command with the
@code{--help} option.
@subsubsection Using the bit_gdb Script
The simplest way to build gdb for RTEMS is to use the @code{bit_gdb} script.
This script interprets the settings in the @code{user.cfg} file to
produce the GDB configuration most appropriate for the target CPU.
The variables in @code{user.cfg} were described in @ref{Using the bit Script}
but only the @code{GDB} variable setting is used by @code{bit_gdb}.
The @code{bit_gdb} script is invoked as follows:
@example
./bit_gdb CPU
@end example
Where CPU is one of the RTEMS supported CPU families from the following
list:
@itemize @bullet
@item hppa1.1
@item i386
@item i386-coff
@item i386-elf
@item i960
@item m68k
@item m68k-coff
@item mips64orion
@item powerpc
@item sh
@item sh-elf
@item sparc
@end itemize
If gdb supports a CPU instruction simulator for this configuration, then
it is included in the build.
@c -------------------
@c
@c Common Problems
@c

130
doc/started/buildrt.t
View File

@@ -119,15 +119,15 @@ error messages.
This section describes how to configure and build RTEMS
so that it is specifically tailored for your BSP and the
CPU model it uses. There are two methods to compile and install RTEMS:
CPU model it uses. There is currently only one supported
method to compile and install RTEMS:
@itemize @bullet
@item direct invocation of @code{configure} and @code{make}
@item using the @code{bit} script
@end itemize
Direct invocation of @code{configure} and @code{make} provides more control
and easier recovery from problems when building.
and easier recovery from problems when building.
This section describes how to build RTEMS.
@@ -168,128 +168,6 @@ tools/@value{RTEMS-UNTAR}/README.configure.
<INSTALL_POINT> is typically the installation point for the
tools and is @code{/opt/rtems} when using prebuilt toolset executables.
NOTE: The @code{make} utility used should be GNU make.
@c
@c Using the bit_rtems Script
@c
@subsection Using the bit_rtems Script
If you have not previously unarchived the build tools, then you
will need to unarchive the build scripts at this point if you
plan to use @code{bit_rtems} to build RTEMS. If this is the
case, you will have to execute the following additional command
since you did not do it as part of building the tools.
@example
cd tools
tar xzf ../archive/@value{BUILDTOOLS-TAR}
@end example
This script interprets the settings in the @code{user.cfg} file to
enable or disable the various RTEMS options. The RTEMS
specific entries described below must be set to
tailor the RTEMS configuration to meet your application requirements:
@table @code
@item RTEMS
is the directory under tools that contains @value{RTEMS-UNTAR}.
@item ENABLE_RTEMS_POSIX
is set to "yes" if you want to enable the RTEMS POSIX API support.
At this time, this feature is not supported by the UNIX ports of RTEMS
and is forced to "no" for those targets. This corresponds to the
@code{configure} option @code{--enable-posix}.
@item ENABLE_RTEMS_ITRON
is set to "yes" if you want to enable the RTEMS ITRON API support.
At this time, this feature is not supported by the UNIX ports of RTEMS
and is forced to "no" for those targets. This corresponds to the
@code{configure} option @code{--enable-itron}.
@item ENABLE_RTEMS_MP
is set to "yes" if you want to enable the RTEMS multiprocessing
support. This feature is not supported by all RTEMS BSPs and
is automatically forced to "no" for those BSPs. This corresponds to the
@code{configure} option @code{--enable-multiprocessing}.
@item ENABLE_RTEMS_CXX
is set to "yes" if you want to build the RTEMS C++ support including
the C++ Wrapper for the Classic API. This corresponds to the
@code{configure} option @code{--enable-cxx}.
@item ENABLE_RTEMS_TESTS
is set to "yes" if you want to build the RTEMS Test Suite. If this
is set to "no", then only the Sample Tests will be built. Setting
this option to "yes" significantly increases the amount of disk
space required to build RTEMS.
This corresponds to the @code{configure} option @code{--enable-tests}.
@item ENABLE_RTEMS_TCPIP
is set to "yes" if you want to build the RTEMS TCP/IP Stack. If a
particular BSP does not support TCP/IP, then this feature is automatically
disabled. This corresponds to the @code{configure} option
@code{--enable-tcpip}.
@item ENABLE_RTEMS_NONDEBUG
is set to "yes" if you want to build RTEMS in a fully optimized
state. This corresponds to executing @code{make} after configuring
the source tree.
@item ENABLE_RTEMS_DEBUG
is set to "yes" if you want to build RTEMS in a debug version.
When built for debug, RTEMS will include run-time code to
perform consistency checks such as heap consistency checks.
Although the precise compilation arguments are BSP dependent,
the debug version of RTEMS is usually built at a lower optimization
level. This is usually done to reduce inlining which can make
tracing code execution difficult. This corresponds to executing
@code{make VARIANT=debug} after configuring
the source tree.
@item INSTALL_RTEMS
is set to "yes" if you want to install RTEMS after building it.
This corresponds to executing @code{make install} after configuring
and building the source tree.
@item ENABLE_RTEMS_MAINTAINER_MODE
is set to "yes" if you want to enabled maintainer mode functionality
in the RTEMS Makefile. This is disabled by default and it is not
expected that most users will want to enable this. When this option
is enabled, the build process may attempt to regenerate files that
require tools not required when this option is disabled.
This corresponds to the @code{configure} option
@code{--enable-maintainer-mode}.
@end table
After tailoring @code{user.cfg} for your application, the @code{bit_rtems}
script may be invoked as follows:
@example
./bit_rtems CPU [BSP]
@end example
Where CPU is one of the RTEMS supported CPU families from the following
list:
@itemize @bullet
@item hppa1.1
@item i386
@item i386-coff
@item i386-elf
@item i960
@item m68k
@item m68k-coff
@item mips64orion
@item powerpc
@item sh
@item sh-elf
@item sparc
@end itemize
BSP is a supported BSP for the selected CPU family. The list of
supported BSPs may be found in the file
tools/@value{RTEMS-UNTAR}/README.configure
@@ -298,3 +176,5 @@ then all supported BSPs for the selected CPU family will be built.
@b{NOTE:} The POSIX API must be enabled to use GNAT/RTEMS.
@b{NOTE:} The @code{make} utility used should be GNU make.

278
doc/started/gdb.t
View File

@@ -1,278 +0,0 @@
@c
@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@chapter Building the GNU Debugger
The GNU Debugger GDB supports many configurations but requires some
means of communicating between the host computer and target board.
This communication can be via a serial port, Ethernet, BDM, or ROM emulator.
The communication protocol can be the GDB remote protocol or GDB
can talk directly to a ROM monitor. This setup is target board
specific. The following configurations have been
successfully used with RTEMS applications:
@itemize @bullet
@item Sparc Instruction Simulator (SIS)
@item PowerPC Instruction Simulator (PSIM)
@item DINK32
@item BDM with 68360 and MPC860 CPUs
@item Motorola Mxxxbug found on M68xxx MVME boards
@item Motorola PPCbug found on PowerPC MVME boards
@end itemize
GDB is currently RTEMS thread/task aware only if you are using the
remote debugging support via Ethernet. These are configured
using gdb targets of the form CPU-RTEMS. Note the capital RTEMS.
It is recommended that when toolset binaries are available for
your particular host, that they be used. Prebuilt binaries
are much easier to install but in the case of gdb may or may
not include support for your particular target board.
@c
@c Getting Ready to Build GDB
@c
@section Getting Ready to Build GDB
This section describes the process of unarchiving GDB
as well as applying RTEMS specific patches. This is required when building
the tools via the instructions in the
@ref{Using the GDB configure Script Directly} or
@ref{Using the bit_gdb Script} sections. It is @b{NOT} required when
using RPM to build tool binaries.
@c
@c Unarchive the GDB Distribution
@c
@subsection Unarchive the GDB Distribution
Unarchive the compressed tar files for GDB using the appropriate
command based upon the compression program used for the source
distribution you downloaded.
@example
cd tools
tar xzf ../archive/@{GDB-UNTAR}.tar.gz # for gzip'ed gdb
tar xIf ../archive/@{GDB-UNTAR}.tar.bz2 # for bzip'ed gdb
@endif
@example
cd tools
tar xzf ../archive/@value{GDB-TAR}
@end example
The directory @value{GDB-UNTAR} is created under the tools directory.
@c
@c Apply RTEMS Patch to GDB
@c
@subsection Apply RTEMS Patch to GDB
@ifclear GDB-RTEMSPATCH
No RTEMS specific patches are required for @value{GDB-VERSION} to
support @value{RTEMS-VERSION}.
@end ifclear
@ifset GDB-RTEMSPATCH
Apply the patch using the following command sequence:
@example
cd tools/@value{GDB-UNTAR}
zcat archive/@value{GDB-RTEMSPATCH} | patch -p1
@end example
Check to see if any of these patches have been rejected using the following
sequence:
@example
cd tools/@value{GDB-UNTAR}
find . -name "*.rej" -print
@end example
If any files are found with the .rej extension, a patch has been rejected.
This should not happen with a good patch file.
@end ifset
@c
@c Building the GNU Debugger GDB
@c
@section Building the GNU Debugger GDB
There are three methods of build the GNU Debugger:
@itemize @bullet
@item RPM
@item direct invocation of configure and make
@item using the @code{bit_gdb} script
@end itemize
Direct invocation of configure and make provides more control
and easier recovery from problems when building.
@c
@c Using RPM to Build GDB
@c
@subsection Using RPM to Build GDB
This section describes the process of building binutils, gcc, and
newlib using RPM. RPM is a packaging format which can be used to
distribute binary files as well as to capture the procedure and
source code used to produce those binary files. Before
attempting to build any RPM from source, it is necessary to
ensure that all required source and patches are in the @code{SOURCES}
directory under the RPM root (probably @code{/usr/src/redhat} or
@code{/usr/local/src/redhat} on your machine. This procedure
starts by installing the source RPMs as shown in the following
example:
@example
rpm -i i386-rtems-gdb-collection-4.18-4.nosrc.rpm
@end example
Because RTEMS tool RPMS are called "nosrc" to indicate that one or
more source files required to produce the RPMs are not present.
The RTEMS source GDB RPM does not include the large @code{.tar.gz} or
@code{.tgz} files for GDB. This is shared by all RTEMS RPMs
regardless of target CPU and there was no reason
to duplicate them. You will have to get the required source
archive files by hand and place them in the @code{SOURCES} directory
before attempting to build. If you forget to do this, RPM is
smart -- it will tell you what is missing. To determine what is
included or referenced by a particular RPM, use a command like the
following:
@example
$ rpm -q -l -p i386-rtems-gdb-collection-4.18-4.nosrc.rpm
gdb-4.18-rtems-20000524.diff
gdb-4.18.tar.gz
i386-rtems-gdb-4.18.spec
@end example
Notice that there is a patch file (the @code{.diff} file), a source archive
file (the @code{.tar.gz}), and a file describing the build procedure and
files produced (the @code{.spec} file). The @code{.spec} file is placed
in the @code{SPECS} directory under the RPM root directory.
c
@c Configuring and Building GDB using RPM
@c
@subsubsection Configuring and Building GDB using RPM
The following example illustrates the invocation of RPM to build a new,
locally compiled, binutils binary RPM that matches the installed source
RPM. This example assumes that all of the required source is installed.
@example
cd <RPM_ROOT_DIRECTORY>/SPECS
rpm -bb i386-rtems-gdb-4.18.spec
@end example
If the build completes successfully, RPMS like the following will
be generated in a build-host architecture specific subdirectory
of the RPMS directory under the RPM root directory.
@example
rtems-base-gdb-4.18-4.i386.rpm
i386-rtems-gdb-4.18-4.i386.rpm
@end example
NOTE: It may be necessary to remove the build tree in the
@code{BUILD} directory under the RPM root directory.
@c
@c Using the GDB configure Script Directly
@c
@subsection Using the GDB configure Script Directly
This section describes how to configure the GNU debugger for
standard RTEMS configurations as well as some alternative
configurations that have been used in the past.
@subsubsection Standard RTEMS GDB Configuration
The following example illustrates the invocation of configure
and make to build and install @value{GDB-UNTAR} for the
m68k-rtems target:
@example
mkdir b-gdb
cd b-gdb
../@value{GDB-UNTAR}/configure --target=m68k-rtems \
--prefix=/opt/rtems
make all
make info
make install
@end example
For some configurations, it is necessary to specify extra options
to @code{configure} to enable and configure option components
such as a processor simulator. The following is a list of
configurations for which there are extra options:
@table @b
@item i960-rtems
@code{--enable-sim}
@item powerpc-rtems
@code{--enable-sim --enable-sim-powerpc --enable-sim-timebase --enable-sim-hardware}
@item sparc-rtems
@code{--enable-sim}
@end table
After @value{GDB-UNTAR} is built and installed the
build directory @code{b-gdb} may be removed.
For more information on the invocation of @code{configure}, please
refer to the documentation for @value{GDB-UNTAR} or
invoke the @value{GDB-UNTAR} configure command with the
@code{--help} option.
@subsection Using the bit_gdb Script
The simplest way to build gdb for RTEMS is to use the @code{bit_gdb} script.
This script interprets the settings in the @code{user.cfg} file to
produce the GDB configuration most appropriate for the target CPU.
This script is invoked as follows:
@example
./bit_gdb CPU
@end example
Where CPU is one of the RTEMS supported CPU families from the following
list:
@itemize @bullet
@item hppa1.1
@item i386
@item i386-coff
@item i386-elf
@item i960
@item m68k
@item m68k-coff
@item mips64orion
@item powerpc
@item sh
@item sh-elf
@item sparc
@end itemize
If gdb supports a CPU instruction simulator for this configuration, then
it is included in the build.

6
doc/started/nt.t
View File

@@ -43,7 +43,7 @@ CYGWIN=nontsec for compile to work properly (otherwise there were
complaints about permissions on a temporary file).
@item If you want to build the tools from source, you have the
same options as UNIX users -- @code{bit} or @code{RPM}.
same options as UNIX users.
@end itemize
@@ -279,7 +279,7 @@ command to configure @value{BINUTILS-VERSION}:
@end example
Replace @code{m68k-rtems} with the target configuration
of your choice. See @ref{Using the bit Script} for a
of your choice. See @ref{Using the RTEMS configure Script Directly} for a
list of the targets available.
@item Execute the following command to compile the toolset:
@@ -357,7 +357,7 @@ or Objective-C as Cygwin32 cross-compilers):
@end example
Replace @code{m68k-rtems} with the target configuration
of your choice. See @ref{Using the bit Script} for a
of your choice. See @ref{Using the RTEMS configure Script Directly} for a
list of the targets available.
@item Compile the toolset as follows:

5
doc/started/require.t
View File

@@ -120,9 +120,8 @@ The following problems have been reported by Solaris 2.x users:
@item The build scripts are written in "shell". The program @code{/bin/sh}
on Solaris 2.x is not robust enough to execute these scripts. If you
are on a Solaris 2.x host, then change the first line of the files
@code{bit}, @code{bit_gdb}, and @code{bit_rtems} to use the
@code{/bin/ksh} shell instead.
are on a Solaris 2.x host, then use the @code{/bin/ksh} or
@code{/bin/bash} shell instead.
@item The native @code{patch} program is broken. Install the GNU version.

26
doc/started/tversions.texi
View File

@@ -21,22 +21,22 @@
@c GCC Version
@c
@set GCC-VERSION gcc 3.1
@set GCC-TAR gcc-3.1.tar.gz
@set GCC-UNTAR gcc-3.1
@set GCC-VERSION gcc 3.2
@set GCC-TAR gcc-3.2.tar.gz
@set GCC-UNTAR gcc-3.2
@set GCC-FTPSITE gcc.gnu.org
@set GCC-FTPDIR /pub/gnu/gcc/
@set GCC-HTTPDIR /pub/gcc/releases/index.html
@set GCC-RTEMSPATCH gcc-3.1-rtems-200205XX.diff.gz
@set GCC-RTEMSPATCH gcc-3.2-rtems-20021107.diff
@c
@c BINUTILS Version
@c
@c The "official" binutils
@set BINUTILS-VERSION binutils 2.12
@set BINUTILS-TAR binutils-2.12.tar.gz
@set BINUTILS-UNTAR binutils-2.12
@set BINUTILS-VERSION binutils 2.13.1
@set BINUTILS-TAR binutils-2.13.1.tar.gz
@set BINUTILS-UNTAR binutils-2.13.1
@set BINUTILS-FTPSITE ftp.gnu.org
@set BINUTILS-FTPDIR /pub/gnu/binutils
@c @set BINUTILS-RTEMSPATCH binutils-2.10-rtems-diff-20001107.gz
@@ -67,7 +67,7 @@
@set NEWLIB-UNTAR newlib-1.10.0
@set NEWLIB-FTPSITE sources.redhat.com
@set NEWLIB-FTPDIR /pub/newlib
@set NEWLIB-RTEMSPATCH newlib-1.10.0-rtems-200205XX.diff.gz
@set NEWLIB-RTEMSPATCH newlib-1.10.0-rtems-20021101.diff.gz
@c
@c GDB Version
@@ -84,11 +84,11 @@
@c RTEMS Version
@c
@set RTEMS-VERSION RTEMS SS-200206XX
@set RTEMS-TAR rtems-ss-200206xx.tgz
@set RTEMS-UNTAR rtems-ss-200206xx
@set RTEMS-VERSION RTEMS SS-20021111
@set RTEMS-TAR rtems-ss-20021111.tar.bz2
@set RTEMS-UNTAR rtems-ss-20021111
@set RTEMS-FTPSITE ftp.OARcorp.com
@set RTEMS-FTPDIR /pub/rtems/releases/4.5.1
@set BUILDTOOLS-TAR c_build_scripts-4.5.1.tgz
@set RTEMS-FTPDIR /pub/rtems/cd-working
@c @set BUILDTOOLS-TAR c_build_scripts-4.5.1.tgz