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

doc/started: simplify and fix

Browse Source 
* fix and remove some macros in rtems.texi.in.
* refer to devel mailing list.
* remove reference to Debian packaging in requirements section.
* remove section on prebuilt tools.
* replace toolset build instructions with link to RSB docs.
* Add a note in building RTEMS section about using RSB.
* Fix URLs

Closes #2291.
This commit is contained in:
Gedare Bloom
2015-03-11 10:29:13 -04:00
parent cf4045630e
commit d84995d28c
8 changed files with 47 additions and 1226 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
doc/common/rtems.texi.in
View File

@@ -1,8 +1,5 @@
@set RTEMSHTTPSITE www.rtems.org
@set RTEMSUSERS rtems-users@@rtems.com
@set RTEMSUSERSSUBSCRIBE rtems-users-subscribe@@rtems.com
@set RTEMSBUGS http://www.rtems.org/bugzilla
@set RTEMSFTPURL ftp://www.rtems.org
@set RTEMSUSERS users@@rtems.org
@set RTEMSDEVEL devel@@rtems.org
@set RTEMSHTTPURL http://www.rtems.org
@set RTEMSPREFIX @RTEMSPREFIX@
@set RTEMSAPI @RTEMSAPI@

20
doc/started/Makefile.am
View File

@@ -8,7 +8,7 @@ PROJECT = started
include $(top_srcdir)/project.am
include $(top_srcdir)/main.am
GENERATED_FILES = binaries.texi buildc.texi buildrt.texi intro.texi nt.texi \
GENERATED_FILES = buildc.texi buildrt.texi intro.texi nt.texi \
require.texi nextstep.texi sample.texi
COMMON_FILES += $(top_srcdir)/common/cpright.texi
@@ -24,23 +24,19 @@ intro.texi: intro.t
-n "Requirements" < $< > $@
require.texi: require.t
$(BMENU2) -c -p "GCC Mailing Lists" \
$(BMENU2) -c -p "RTEMS Mailing Lists" \
-u "Top" \
-n "Prebuilt Toolset Executables" < $< > $@
binaries.texi: binaries.t
$(BMENU2) -c \
-p "GNU/Linux Distributions using Debian Packaging Format" \
-u "Top" \
-n "Building the GNU Cross Compiler Toolset" < $< > $@
-n "Building the GNU Cross Compiler Toolset with RSB" < $< > $@
buildc.texi: buildc.t
$(BMENU2) -c -p "Removing Zipped Tar Files" \
$(BMENU2) -c \
-p "Distribution Independent Potential GNU/Linux Issues" \
-u "Top" \
-n "Building RTEMS" < $< > $@
buildrt.texi: buildrt.t
$(BMENU2) -c -p "Error Messages Indicating Configuration Problems" \
$(BMENU2) -c \
-p "Building the GNU Cross Compiler Toolset with RSB" \
-u "Top" \
-n "Building the Sample Applications" < $< > $@
@@ -59,7 +55,7 @@ nt.texi: nt.t
-u "Top" \
-n "" < $< > $@
EXTRA_DIST = binaries.t buildc.t buildrt.t intro.t nextstep.t nt.t require.t \
EXTRA_DIST = buildc.t buildrt.t intro.t nextstep.t nt.t require.t \
sample.t
if USE_HTML

341
doc/started/binaries.t
View File

@@ -1,341 +0,0 @@
@c
@c COPYRIGHT (c) 1988-2010.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@chapter Prebuilt Toolset Executables
Precompiled toolsets are available for GNU/Linux and MS-Windows.
Other hosts will need to build from source. Packaged binaries are
in the following formats:
@itemize @bullet
@item GNU/Linux - RPM
@item Cygwin - tar.bz2
@item Mingw - tar.bz2
@end itemize
RPM is an acronym for the RPM Package Manager. RPM is the native package
installer for many GNU/Linux distributions including RedHat Enterprise
Linux, Centos, SuSE, and Fedora.
The RTEMS Project maintains a Yum Repository which makes it quite simple
to install and update RTEMS toolsets.
The prebuilt binaries are intended to be easy to install and
the instructions are similar regardless of the host environment.
There are a few structural issues with the packaging of the RTEMS
Cross Toolset binaries that you need to be aware of.
@enumerate
@item There are dependencies between the various packages. This requires
that certain packages be installed before others may be. Some packaging
formats enforce this dependency.
@item Some packages are target CPU family independent and shared
across all target architectures. These are referred to as
"base" packages.
@item Pre-built GNU Binary Utilities (binutils) packages are available
for all RTEMS targets. These include tools such as the assembler and
linker and must be installed.
@item Pre-built C language packages are available which include a C
compiler as well as the Standard C libraries for the embedded RTEMS
targets. These must be installed.
@item Pre-built C++ language packages are available for most target
architectures which includes a C++ compiler as well as the Standard C++
libraries for the embedded RTEMS targets. These are not part of the
minimum installation and need only be installed if the application is
using C++.
@end enumerate
NOTE: Installing toolset binaries does not install RTEMS itself, only
the tools required to build RTEMS. See @ref{Building RTEMS} for the next
step in the process.
@section RPMs
This section provides information on installing and removing RPMs.
Note that RTEMS tools for multiple major versions of RTEMS can be
installed in parallel since they are installed into different host
directories. The tools also include the RTEMS Release Series in their
name.
@subsection Locating the RPMs for your GNU/Linux Distribution
The RTEMS Project maintains a Yum Repository of RPMs for its
toolsets. Whether you use Yum to install the RPMs or download and install
them via another procedure, you will need to locate the appropriate
set of RPMs on the RTEMS Yum Repository. The following instructions
are generalized.
If your host operating system uses Yum and RPMs, then you will only have
to download and install two RPMs by hand
@enumerate
@item Point your browser at
@uref{http://www.rtems.org/ftp/pub/rtems/linux,
http://www.rtems.org/ftp/pub/rtems/linux}. In this directory, you
will see a list of RTEMS major versions such as 4.11, 4.10, 4.9, etc..
Descend into the appropriate directory for the version of RTEMS you
are using.
@item Now that you are in the directory for a specific RTEMS major
version, you will be presented with a list of GNU/Linux distributions.
This will include options like redhat, centos, fedora, and suse.
Select the appropriate distribution.
@item Now that you are in the directory for your selected distribution,
you will be presented with a list of distribution versions for which
RTEMS pre-built RPMs are available. Select the appropriate distribution
version.
@item Now that you are in the directory for the proper version of
your selected distribution, you will be presented with a choice of
host architecture versions such as i386, i686, and x86_64. Select the
appropriate version for your development computer.
@item At this point, you will have a long list of RPMs to select from.
@end enumerate
The RTEMS Projects supports a wide variety of host OS and target
combinations. In addition, these toolsets are specific to a particular
RTEMS Release Series. Given the large number of possible combinations,
the instructions use variables to indicate where versions go in the real
package names you will use. These variable are used in the examples of
RPM version names:
@itemize @bullet
@item @code{<VERSION>} is the tool version will be found at this location
in the RPM name. This will be a release number such as @code{2.20}
or @code{4.4.5}.
@item @code{<DIST>} indicates the GNU/Linux distribution version.
This will be a string such as @code{fc14} or @code{el6}.
@item @code{<ARCH>} indicates the architecture used for RPMs on your
GNU/Linux installation. This will be a string such as @code{i386}
or @code{x86_64}.
@item @code{<RPM>} indicates the RPM revision level. This will be a
single integer.
@end itemize
The tool VERSION and RPM release may vary within the set of current RPMs for a particular RTEMS Release series based upon the target architecture.
If you are using Yum, please continue to the next section. If you are
downloading the RPMs to install by hand, then go to the @ref{Installing
RPMs Without Yum} section.
@subsection Managing RPMs Using Yum
This section describes how to install and remove RTEMS Toolsets using Yum.
@subsubsection Installing RPMs Using Yum
If you are on a host operating system that uses Yum, you are fortunate because this is the one of the simplest ways to install the tools. After locating the appropriate directory on the RTEMS Yum Repository using the instructions in @ref{Locating the RPMs for your GNU/Linux Distribution}, you will need to install the following RPMs:
@itemize @bullet
@item @value{RTEMSRPMPREFIX}-release-<VERSION>-<RPM>.<DIST>.noarch.rpm
@item @value{RTEMSRPMPREFIX}-yum-conf-<VERSION>-<RPM>.<DIST>.noarch.rpm
@end itemize
You can use the search within page feature of your browser to locate
the RPMs with "release" or "yum" in their names.
You will need to download the RPMs above or RPM can be given the URLs for
them and it will fetch them for you. Either way, the commands similar
to the following will install the common or base RPMs required.
@example
rpm -U @value{RTEMSRPMPREFIX}-release-<VERSION>-<RPM>.<DIST>.noarch.rpm \
@value{RTEMSRPMPREFIX}-yum-conf-<VERSION>-<RPM>.<DIST>.noarch.rpm
@end example
Once these are installed, Yum knows about the RTEMS Yum repository
for @value{RTEMSPREFIX}. This means that you can install and upgrade
RTEMS Toolsets just like the packages provided by your distribution.
To install complete C and C++ toolset targeting the SPARC architecture
for the RTEMS @value{RTEMSAPI} Release series, commands similar to the
following will be used.
@example
yum install @value{RTEMSPREFIX}-auto*
yum install @value{RTEMSPREFIX}-sparc-*
@end example
The first command installs GNU autoconf and automake which are used
by all RTEMS targets. The second command installs the complete
sparc-@value{RTEMSPREFIX} toolset including all dependencies.
@subsubsection Removing RPMs Using Yum
The following is a sample session illustrating the removal of a C/C++
toolset targeting the SPARC architecture.
@example
yum erase @value{RTEMSRPMPREFIX}-sparc-*
@end example
If this is the last target architecture for which tools are installed, then you can remove the RTEMS GNU autotools and common packages as follows:
@example
yum erase @value{RTEMSRPMPREFIX}-auto*
yum erase @value{RTEMSRPMPREFIX}-*common*
@end example
NOTE: If you have installed any RTEMS BSPs, then it is likely that RPM
will complain about not being able to remove everything. These will
have to be removed by hand.
@subsection Managing RPMs Without Using Yum
This section describes how to install and remove RTEMS Toolsets without
using Yum. This is NOT expected to be the norm for RPM users.
@subsubsection Installing RPMs Without Yum
The following is a sample session illustrating the installation of the
complete C and C++ toolset targeting the SPARC architecture for the
RTEMS @value{RTEMSAPI} Release series.
Since you are not using Yum, you will need to download all of the RPMs
you will install. Alternatively, RPM can be given a URL for an RPM file
and it will fetch it for you. Either way, the commands similar to the
following will install the common or base RPMs required.
@example
rpm -U @value{RTEMSRPMPREFIX}binutils-common-<VERSION>-<RPM>.<DIST>.noarch.rpm \
@value{RTEMSRPMPREFIX}gcc-common-<VERSION>-<RPM>.<DIST>.noarch.rpm \
@value{RTEMSRPMPREFIX}newlib-common-<VERSION>-<RPM>.<DIST>.noarch.rpm \
@value{RTEMSRPMPREFIX}gdb-common-<VERSION>-<RPM>.<DIST>.noarch.rpm
@end example
The above RPMs are shared across all RTEMS targets and include common
files such as the documentation. The following illustrates how to install
the GNU Autoconf and Automake RPMs that match your RTEMS installation.
RTEMS uses the GNU Autotools for its configure and build infrastructure
and you will need these if you modify the build infrastructure or check
out RTEMS from CVS and have to bootstrap the source tree.
@example
rpm -U @value{RTEMSRPMPREFIX}autoconf-<VERSION>-<RPM>.<DIST>.noarch.rpm \
@value{RTEMSRPMPREFIX}automake-<VERSION>-<RPM>.<DIST>.noarch.rpm
@end example
Now that you have installed all of the RPMs that are independent of the
target architecture you can install the C toolset for a specific target.
The following command will install the target architecture specific set
of the RPMs for a C toolset including GDB.
@example
rpm -U @value{RTEMSRPMPREFIX}sparc-rtems@value{RTEMSAPI}-binutils-<VERSION>-<RPM>.<ARCH>.rpm \
@value{RTEMSRPMPREFIX}sparc-rtems@value{RTEMSAPI}-gcc-<VERSION>-<RPM>.<ARCH>.rpm \
@value{RTEMSRPMPREFIX}sparc-rtems@value{RTEMSAPI}-newlib-<VERSION>-<RPM>.<ARCH>.rpm \
@value{RTEMSRPMPREFIX}sparc-rtems@value{RTEMSAPI}-libgcc-<VERSION>-<RPM>.<ARCH>.rpm \
@value{RTEMSRPMPREFIX}sparc-rtems@value{RTEMSAPI}-gdb-<VERSION>-<RPM>.<ARCH>.rpm
@end example
The following command illustrates how to install the C++ specific portion of the RPMs.
@example
rpm -U @value{RTEMSRPMPREFIX}sparc-rtems@value{RTEMSAPI}-gcc-c++-<VERSION>-<RPM>.<ARCH>.rpm \
@value{RTEMSRPMPREFIX}sparc-rtems@value{RTEMSAPI}-libstd++-<VERSION>-<RPM>.<ARCH>.rpm
@end example
Upon successful completion of the above command sequence, a C/C++
cross development toolset targeting the SPARC is installed in
@code{@value{RTEMSPREFIX}}. In order to use this toolset, the directory
@code{@value{RTEMSPREFIX}/bin} should be at the start of your PATH.
At this point, the tools are installed for a specific target architecture
adn you may proceed directly to @ref{Building RTEMS}.
If you want to build RTEMS for multiple target architectures, you will
need to install the target specific portion of the RPMs for each target.
@subsubsection Removing RPMs Without Using Yum
The following is a sample session illustrating the removal of a C/C++
toolset targeting the SPARC architecture.
@example
rpm -e `rpm -qa | grep @value{RTEMSRPMPREFIX}-sparc-`
@end example
If this is the last target architecture for which tools are installed, then you can remove the RTEMS GNU autotools and common packages as follows:
@example
rpm -e `rpm -qa | grep @value{RTEMSRPMPREFIX}-auto`
rpm -e `rpm -qa | grep @value{RTEMSRPMPREFIX} | grep common`
@end example
NOTE: If you have installed any RTEMS BSPs, then it is likely that RPM
will complain about not being able to remove everything. These will
have to be removed by hand.
@subsection Determining Which RTEMS RPMs are Installed
The following command will report which RTEMS RPMs are currently
installed:
@example
rpm -qa | grep @value{RTEMSAPI}
@end example
@section Zipped Tar Files
The tool binaries for some hosts are provided as compressed tar files.
This section provides information on installing and removing Zipped Tar
Files (e.g .tar.gz or .tar.bz2).
@subsection Installing Zipped Tar Files
The following is a sample session illustrating the installation
of a C/C++ toolset targeting the SPARC architecture assuming
that GNU tar is installed as @code{tar} for a set of archive
files compressed with GNU Zip (gzip):
@example
cd /
tar xzf @value{RTEMSRPMPREFIX}binutils-common-<VERSION>-<RPM>.tar.gz
tar xzf @value{RTEMSRPMPREFIX}sparc-rtems@value{RTEMSAPI}-binutils-<VERSION>-<RPM>.tar.gz
tar xzf @value{RTEMSRPMPREFIX}gcc-common-<VERSION>-<RPM>.tar.gz
tar xzf @value{RTEMSRPMPREFIX}sparc-rtems@value{RTEMSAPI}-gcc-<VERSION>-<RPM>.tar.gz
tar xzf @value{RTEMSRPMPREFIX}sparc-rtems@value{RTEMSAPI}-newlib-<VERSION>-<RPM>.tar.gz
tar xzf @value{RTEMSRPMPREFIX}gdb-common-<VERSION>-<RPM>.tar.gz
tar xzf @value{RTEMSRPMPREFIX}sparc-rtems@value{RTEMSAPI}-gdb-<VERSION>-<RPM>.tar.gz
@end example
The following command set is the equivalent command sequence
for the same toolset assuming that is was compressed with
GNU BZip (bzip2):
@example
cd /
tar xjf @value{RTEMSRPMPREFIX}binutils-common-<VERSION>-<RPM>.tar.bz2
tar xjf @value{RTEMSRPMPREFIX}sparc-rtems@value{RTEMSAPI}-binutils-<VERSION>-<RPM>.tar.bz2
tar xjf @value{RTEMSRPMPREFIX}gcc-common-<VERSION>-<RPM>.tar.bz2
tar xjf @value{RTEMSRPMPREFIX}sparc-rtems@value{RTEMSAPI}-newlib-<VERSION>-<RPM>.tar.bz2
tar xjf @value{RTEMSRPMPREFIX}sparc-rtems@value{RTEMSAPI}-gcc-<VERSION>-<RPM>.tar.bz2
tar xjf @value{RTEMSRPMPREFIX}gdb-common-<VERSION>-<RPM>.tar.bz2
tar xjf @value{RTEMSRPMPREFIX}sparc-rtems@value{RTEMSAPI}-gdb-<VERSION>-<RPM>.tar.bz2
@end example
Upon successful completion of the above command sequence, a
C/C++ cross development toolset targeting the SPARC is
installed in @code{@value{RTEMSPREFIX}}. In order to use this toolset,
the directory @code{@value{RTEMSPREFIX}} must be included in your
PATH.
@subsection Removing Zipped Tar Files
There is no automatic way to remove the contents of a @code{tar.gz}
or @code{tar.bz2} once it is installed. The contents of the directory
@code{@value{RTEMSPREFIX}} can be removed but this will likely result
in other packages being removed as well.

829
doc/started/buildc.t
View File

@@ -3,827 +3,14 @@
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@chapter Building the GNU Cross Compiler Toolset
@chapter Building the GNU Cross Compiler Toolset with RSB
@b{NOTE}: This chapter describes the steps required to build cross-compilation
toolset on Linux (and possibly Windows using Cygwin) systems. This chapter
does @b{NOT} apply if you installed prebuilt toolset executables for BINUTILS,
GCC, NEWLIB, and GDB. If you installed prebuilt executables for all of those,
proceed to @ref{Building RTEMS}. If you require a GDB with a special
configuration to connect to your target board, then proceed to
@ref{Installing GDB Without RPM} for some advice.
The RTEMS Projects recommends using the RTEMS Source Builder (RSB)
for building the toolset from source. RSB has evolved over time from
various instructions and scripts for building the toolset, and it removes
much of the frustration associated with building the toolset from source.
Although prebuilt binaries are much easier to install, they are harder
for the RTEMS Project to support.
This chapter describes the steps required to acquire the source code for
a GNU cross compiler toolset, apply any required RTEMS specific patches,
compile that toolset and install it.
Documentation for RSB is available from @uref{https://docs.rtems.org/rsb/,https://docs.rtems.org/rsb/}.
It is recommended that when toolset binaries are available for your
particular host, that they be used. Prebuilt binaries are much easier
to install. They are also much easier for the RTEMS Project to support.
@c
@c Preparation
@c
@section Preparation
Before you can build an RTEMS toolset from source, there are some
preparatory steps which must be performed. You will need to determine
the various tool versions and patches required and download them You
will also have to unarchive the source and apply any patches.
@c
@c Determining Tool Version and Patch Revision
@c
@subsection Determining Tool Version and Patch Revision
The tool versions and patch revisions change on a fairly frequent basis.
In addition, these may vary based upon the target architecture. In some
cases, the RTEMS Project may have to stick with a particular version
of a tool to provide a working version for a specific architecture.
Because of this, it is impossible to provide this information in a
complete and accurate manner in this manual. You will need to refer
to the configuration files used by the RTEMS RPM specification files to
determine the current versions and, if a patch is required, what version.
This section describes how to locate the appropriate tool versions and
patches for a particular target architecture.
All patches and RPM specification files are kept under source code
control. They are not included in release tarballs. You will have to
access the CVS branch for RTEMS @value{RTEMSAPI}. For details on this,
visit @uref{http://wiki.rtems.org/wiki/index.php/RTEMS_GIT_Repository,
http://wiki.rtems.org/wiki/index.php/RTEMS_GIT_Repository} and look for
instructions on accessing the RTEMS Source Code Repository in read-only
mode.
In the checked out source code, you will need to look in the subdirectory
@code{contrib/crossrpms/autotools} to determine the versions of AUTOCONF
and AUTOMAKE as well as any patches required. In this directory are
a few files you will need to look at. The first is @code{Makefile.am}
which defines the versions of AUTOCONF and AUTOMAKE required for this
RTEMS Release Series. Make a note of the version numbers required for
AUTOCONF and AUTOMAKE (AUTOCONF_VERS and AUTOMAKE_VERS respectively). Then
examine the following files to determine the master location for the source
tarballs and to determine if a patch is required for each tool version cited in
the @code{Makefile.am}.
@example
autoconf-sources.add
automake-sources.add
@end example
If any patches are required, they will be in the
@code{contrib/crossrpms/patches} subdirectory of your checked out RTEMS
source tree.
If no patches are required, you can use a package manager provided by your
Linux distribution to install AUTOMAKE and AUTOCONF to avoid building them from
source.
In the checked out source code, you will need to look in the subdirectory
@code{contrib/crossrpms/rtems@value{RTEMSAPI}} to determine the target
specific tool versions and patches required. In this directory, you
will find a number of subdirectories with many named after target
architectures supported by RTEMS. Descend into the directory for the
architecture you plan to build tools for. Again, the @code{Makefile.am}
defines the tool versions for this architecture and RTEMS Release Series.
Make a note of the version numbers required for BINUTILS, GCC, NEWLIB,
and GDB. Then examine the following files to determine the master
location for the source tarballs and to determine if a patch is required
for each tool version cited in the @code{Makefile.am}.
@itemize
@item binutils-sources.add
@item gcc-sources.add
@item gdb-sources.add
@end itemize
If any patches are required, they will be in the
@code{contrib/crossrpms/patches} subdirectory of your checked out RTEMS
source tree.
This is the entire set of source tarballs and patches required for a
toolset targeting the selected architecture. In many cases, this will be
the same versions required by other targets on this RTEMS Release Series.
@c
@c Obtain Source and Patches
@c
@subsection Obtain Source and Patches
You will need to download the sources for the various packages from
their master locations as identified in the previous section.
Any patches needed should be in the @code{contrib/crossrpms/patches}
directory of your RTEMS source.
@c
@c Installing the Tools Without RPM
@c
@section Installing the Tools Without RPM
This section describes the procedure for building and installing an RTEMS
cross toolset from source code without using the RPM build infrastructure.
Direct invocation of @code{configure} and @code{make} provides more control
and easier recovery from problems when building.
@c
@c Archive and Build Directory Format
@c
@subsection Archive and Build Directory Format
When no packaging format requirements are present, the root directory for
the storage of source archives and patches as well as for building the
tools is up to the user. The only concern is that there be enough
disk space to complete the build. In this document, the following
organization will be used.
Make an @code{archive} directory to contain the downloaded source code
and pataches. Additionally, a @code{tools} directory to be used as a
build directory. The command sequence to do this is shown below:
@example
mkdir archive
mkdir tools
@end example
This will result in an initial directory structure similar to the
one shown in the following figure:
@example
@group
/whatever/prefix/you/choose/
archive/
tools/
@end group
@end example
The RTEMS Project tries to submit all of our patches upstream to the
parent projects. In the event there are patches, the master copy of them
is located in the appropriate branch of the RTEMS source module in CVS.
Patches are in the @code{contrib/crossrpms/patches}.
@c
@c Unarchiving the Tools
@c
@subsection Unarchiving the Tools
@b{NOTE}: This step is required if building any of the tools without using RPM.
It is @b{NOT} required if using the procedure described in @ref{Using RPM
to Build Tools}. This section describes the process of unarchiving the
tools that comprise an RTEMS toolset.
GNU source distributions are archived using @code{tar} and
compressed using either @code{gzip} or @code{bzip}.
If compressed with @code{gzip}, the extension @code{.gz} is used.
If compressed with @code{bzip}, the extension @code{.bz2} is used.
While in the @code{tools} directory, unpack the compressed tar files
using the appropriate command based upon the compression program used.
@example
cd tools
tar xzf ../archive/TOOLNAME.tar.gz # for gzip'ed tools
tar xjf ../archive/TOOLNAME.tar.bz2 # for bzip'ed tools
@end example
Assuming you are building a complete toolset, after all of the the
compressed tar files have been unpacked using the appropriate commands,
the following directories will have been created under @code{tools}.
@itemize @bullet
@item autoconf-<VERSION>
@item automake-<VERSION>
@item binutils-<VERSION>
@item gcc-<VERSION>
@item newlib-<VERSION>
@item gdb-<VERSION>
@end itemize
The tree should look something like the following figure:
@example
@group
/whatever/prefix/you/choose/
archive/
variable tarballs
variable patches
tools/
various tool source trees
@end group
@end example
@c
@c Applying RTEMS Project Tool Patches
@c
@subsection Applying RTEMS Project Tool Patches
@b{NOTE}: This step is required if building any of the tools IF they have a
patch currently required and you are building the tools without using RPM.
is @b{NOT} required if using the procedure described in @ref{Using RPM
to Build Tools}. This section describes the process of applying the
RTEMS patches to any of the tools.
If a patch is required for a particular tool source tree, it is placed in the
@code{contrib/crossrpms/patches} directory in the CVS tree. Make sure the
patch version is the same as of the tool you are building. You will perform a
command similar to the following to apply the patch. In this example, <TOOL>
should be replaced by the appropriate tool directory and <TOOL_PATCH> with the
appropriate patch file.
@example
cd tools/<TOOL>
cat ../../archive/<TOOL_PATCH> | patch -p1
@end example
@b{NOTE}: If you add the @code{--dry-run} option to the @code{patch} command
in the above commands, it will attempt to apply the patch and report
any issues without actually modifying any files.
If the patch was compressed with the @code{gzip} program, it will
have a suffix of @code{.gz} and you should use @code{zcat} instead
of @code{cat} as shown above. If the patch was compressed with
the @code{gzip} program, it will have a suffix of @code{.bz2} and
you should use @code{bzcat} instead of @code{cat} as shown above.
Check to see if any of these patches have been rejected using the following
sequence:
@example
cd tools/<TOOL>
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 which is properly applied.
@c
@c Installing AUTOCONF From Source
@c
@subsection Installing AUTOCONF From Source
The following example illustrates the invocation of @code{configure}
and @code{make} to build and install autoconf-<version>. This tool is
installed as a native utility and is independent of any RTEMS target.
@b{NOTE}: If no patch is required for Autoconf and Automake, you can use the
standard package manager provided by your Linux distribution to install them.
Of course, the versions provided by your package manager should be the same
that specified in Makefile.am or better.
@example
mkdir b-autoconf
cd b-autoconf
../autoconf-<VERSION>/configure --prefix=@value{RTEMSPREFIX}
make
make install
@end example
After autoconf-<VERSION> is built and installed the build directory
@code{b-autoconf} may be removed.
For more information on the invocation of @code{configure}, please
refer to the documentation for autoconf-<VERSION> or invoke the
autoconf-VERSION> @code{configure} command with the @code{--help} option.
@c
@c Installing AUTOMAKE From Source
@c
@subsection Installing AUTOMAKE From Source
The following example illustrates the invocation of @code{configure}
and @code{make} to build and install automake-<version>. This tool is
installed as a native utility and is independent of any RTEMS target.
@example
mkdir b-automake
cd b-automake
../automake-<VERSION>/configure --prefix=@value{RTEMSPREFIX}
make all
make info
make install
@end example
After automake-<VERSION> is built and installed the build directory
@code{b-automake} may be removed.
For more information on the invocation of @code{configure}, please
refer to the documentation for automake-<VERSION> or invoke the
automake-VERSION> @code{configure} command with the @code{--help} option.
@c
@c Installing BINUTILS From Source
@c
@subsection Installing BINUTILS From Source
The following example illustrates the invocation of @code{configure}
and @code{make} to build and install binutils-<version>
sparc-rtems@value{RTEMSAPI} target:
@example
mkdir b-binutils
cd b-binutils
../binutils-<VERSION>/configure --target=sparc-rtems@value{RTEMSAPI} \
--prefix=@value{RTEMSPREFIX}
make all
make info
make install
@end example
After binutils-<VERSION> is built and installed the build directory
@code{b-binutils} may be removed.
For more information on the invocation of @code{configure}, please
refer to the documentation for binutils-<VERSION> or invoke the
binutils-VERSION> @code{configure} command with the @code{--help} option.
NOTE: The shell PATH variable needs to be updated to include the path
the binutils user executables have been installed in. The directory
containing the executables is the prefix used above with
@file{bin} post-fixed.
@example
export PATH=@value{RTEMSPREFIX}/bin:$@{PATH@}
@end example
As you will need to frequently run various commands in the
@value{RTEMSPREFIX}/bin, you can update your @code{~/.bashrc} to include this
line. After doing that, don't forget to run
@example
source ~/.bashrc
@end example
for the changes to take place.
Failure to have the binutils in the path will cause the GCC and NEWLIB
build to fail with an error message similar to:
@example
sparc-rtems@value{RTEMSAPI}-ar: command not found
@end example
@c
@c Installing GCC and NEWLIB Without RPM
@c
@subsection Installing GCC and NEWLIB Without RPM
Before building gcc-<VERSION> and newlib-<VERSION>,
binutils-<VERSION> must be installed and the directory
containing those executables must be in your PATH.
The C Library is built as a subordinate component of
gcc-<VERSION>. Because of this, the newlib-<VERSION>
directory source must be available inside the gcc-<VERSION>
source tree. This is normally accomplished using a symbolic
link as shown in this example:
@example
cd gcc-<VERSION>
ln -s ../newlib-<VERSION>/newlib .
@end example
The following example illustrates the invocation of
@code{configure} and @code{make}
to build and install gcc-<VERSION> with only
C and C++ support for the sparc-rtems@value{RTEMSAPI} target:
@example
mkdir b-gcc
cd b-gcc
../gcc-<VERSION>/configure --target=sparc-rtems@value{RTEMSAPI} \
--with-gnu-as --with-gnu-ld --with-newlib --verbose \
--enable-threads --enable-languages="c,c++" \
--prefix=@value{RTEMSPREFIX}
make all
make info
make install
@end example
After gcc-<VERSION> is built and installed the
build directory @code{b-gcc} may be removed.
For more information on the invocation of @code{configure}, please
refer to the documentation for gcc-<VERSION> or
invoke the gcc-<VERSION> @code{configure} command with the
@code{--help} option.
@c
@c Building GCC with Ada Support
@c
@subsection Building GCC with Ada Support
If you want a GCC toolset that includes support for Ada
(e.g. GNAT), there are some additional requirements on
the host environment and additional build steps to perform.
It is critical that you use the same version of GCC/GNAT as
the native compiler. GNAT must be compiled with an Ada compiler
and when building a GNAT cross-compiler, it should be
the same version of GNAT itself.
It is also important to verify whether there is an RTEMS specific
Ada patch required for GCC. These can be found in
@uref{http://www.rtems.org/ftp/pub/rtems/people/joel/ada,
http://www.rtems.org/ftp/pub/rtems/people/joel/ada}. The patch is
often a minor version or two behind GCC but will usually apply cleanly.
This patch must be applied.
After this, it is critical to perform these steps in the correct order.
GNAT requires that the C Library and RTEMS itself be installed before
the language run-time can be built.
@itemize @bullet
@item install native GCC with GNAT
@item place new native GNAT at head of PATH
@item install BINUTILS
@item place RTEMS prefix at head of PATH
@item install C toolset (C++ is optional)
@item install RTEMS built multilib
@item install RTEMS built for your BSP
@end itemize
The build procedure is the same until the Ada configure step. A GCC
toolset with GNAT enabled requires that @code{ada} be included in the set
of enabled languages. The following example illustrates the invocation of
@code{configure} and @code{make} to build and install gcc-<VERSION> with
only C, C++, and Ada support for the sparc-rtems@value{RTEMSAPI} target:
@example
mkdir b-gcc
cd b-gcc
../gcc-<VERSION>/configure --target=sparc-rtems@value{RTEMSAPI} \
--with-gnu-as --with-gnu-ld --with-newlib --verbose \
--enable-threads --enable-languages="c,c++,ada" \
--prefix=@value{RTEMSPREFIX}
make all
make info
make install
@end example
After gcc-<VERSION> is built and installed the build directory
@code{b-gcc} may be removed.
@c
@c Installing GDB Without RPM
@c
@subsection Installing GDB Without RPM
@b{NOTE}: This step is NOT required if prebuilt executables for the
GDB were installed and they meet your target interface
requirements.
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. Some of the configurations that have
been successfully used with RTEMS applications are:
@itemize @bullet
@item BDM with ColdFire, 683xx, MPC860 CPUs
@item Motorola Mxxxbug found on M68xxx VME boards
@item Motorola PPCbug found on PowerPC VME, CompactPCI, and MTX boards
@item ARM based Cogent EDB7312
@item PC's using various Intel and AMD CPUs including i386,
i486, Pentium and above, and Athlon
@item PowerPC Instruction Simulator in GDB (PSIM)
@item MIPS Instruction Simulator in GDB (JMR3904)
@item Sparc Instruction Simulator in GDB (SIS)
@item Sparc Instruction Simulator (TSIM)
@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.
The following example illustrates the invocation of @code{configure}
and @code{make} to build and install gdb-<VERSION> for the
m68k-rtems@value{RTEMSAPI} target:
@example
mkdir b-gdb
cd b-gdb
../gdb-<VERSION>/configure --target=m68k-rtems@value{RTEMSAPI} \
--prefix=@value{RTEMSPREFIX}
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 powerpc-rtems@value{RTEMSAPI}
@code{--enable-sim --enable-sim-powerpc --enable-sim-timebase --enable-sim-hardware}
@item sparc-rtems@value{RTEMSAPI}
@code{--enable-sim}
@end table
After gdb-<VERSION> 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 gdb-<VERSION> or
invoke the gdb-<VERSION> @code{configure} command with the
@code{--help} option.
@c
@c Using RPM to Build Tools
@c
@section Using RPM to Build Tools
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. For RPM, it is assumed that the following subdirectories
are under a root directory such as @code{/usr/src/redhat} or
@code{/usr/local/src/redhat}) on your machine.
@example
BUILD
RPMS
SOURCES
SPECS
SRPMS
@end example
For the purposes of this document, the RPM @code{SOURCES} directory is the
directory into which all tool source and patches are assumed to reside.
The @code{BUILD} directory is where the actual build is performed when
building binaries from a source RPM.
RPM automatically unarchives the source and applies any needed patches
so you do @b{NOT} have to manually perform the procedures described
@ref{Unarchiving the Tools} and @ref{Applying RTEMS Project Tool Patches}.
But you are responsible for placing all source tarballs
and patches in the @code{SOURCES} directory per the instructions in
@ref{Obtain Source and Patches}
This procedure starts by installing the source (e.g. @code{.src.rpm}
extension) RPMs. The RTEMS tool source RPMS are called "nosrc" to
indicate that one or more source files required to produce the RPMs
are not present. The RTEMS source RPMs typically include all required
patches, but do not include the large @code{.tar.gz} or @code{.tgz} files
for each component such as BINUTILS, GCC, or NEWLIB. These are 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. You can fetch any missing files and try again.
@c
@c Building AUTOCONF using RPM
@c
@subsection Building AUTOCONF using RPM
This section illustrates the invocation of RPM to build a new, locally
compiled, AUTOCONF binary RPM that matches the installed source RPM.
This example assumes that all of the required source is installed.
@example
rpm -U @value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-autoconf-<VERSION>-<RPM_RELEASE>.src.rpm
@end example
@example
cd <RPM_ROOT_DIRECTORY>/SPECS
rpm -bb i386-rtems@value{RTEMSAPI}-autoconf-<VERSION>.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
@value{RTEMSRPMPREFIX}rtems@value{RTEMSAPI}-autoconf-<VERSION>-<RPM_RELEASE>.<ARCH>.rpm
@end example
@b{NOTE}: It may be necessary to remove the build tree in the @code{BUILD}
directory under the RPM root directory.
@c
@c Building AUTOMAKE using RPM
@c
@subsection Building AUTOMAKE using RPM
This section illustrates the invocation of RPM to build a new, locally
compiled, AUTOMAKE binary RPM that matches the installed source RPM.
This example assumes that all of the required source is installed.
@example
rpm -U @value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-automake-<VERSION>-<RPM_RELEASE>.src.rpm
@end example
@example
cd <RPM_ROOT_DIRECTORY>/SPECS
rpm -bb i386-rtems@value{RTEMSAPI}-automake-<VERSION>.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
@value{RTEMSRPMPREFIX}rtems@value{RTEMSAPI}-automake-<VERSION>-<RPM_RELEASE>.<ARCH>.rpm
@end example
@b{NOTE}: It may be necessary to remove the build tree in the @code{BUILD}
directory under the RPM root directory.
@c
@c Building BINUTILS using RPM
@c
@subsection Building BINUTILS using RPM
This section 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
rpm -U @value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-binutils-<VERSION>-<RPM_RELEASE>.src.rpm
@end example
@example
cd <RPM_ROOT_DIRECTORY>/SPECS
rpm -bb i386-rtems@value{RTEMSAPI}-binutils-<VERSION>.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
@value{RTEMSRPMPREFIX}binutils-common-<VERSION>-<RPM_RELEASE>.<ARCH>.rpm
@value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-binutils-<VERSION>-<RPM_RELEASE>.<ARCH>.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 Building GCC and NEWLIB using RPM
@c
@subsection Building GCC and NEWLIB using RPM
This section illustrates the invocation of RPM to build a new,
locally compiled, set of GCC and NEWLIB binary RPMs that match the
installed source RPM. It is also necessary to install the BINUTILS
RPMs and place them in your PATH. This example assumes that all of
the required source is installed.
@example
cd <RPM_ROOT_DIRECTORY>/SPECS
rpm -bb i386-rtems@value{RTEMSAPI}-gcc-<VERSION>.spec
@end example
If the build completes successfully, a set of RPMS like the following will
be generated in a build-host architecture specific subdirectory
of the RPMS directory under the RPM root directory.
@example
@value{RTEMSRPMPREFIX}gcc-common-<VERSION>-<RPM>.<DIST>.noarch.rpm \
@value{RTEMSRPMPREFIX}newlib-common-<VERSION>-<RPM>.<DIST>.noarch.rpm \
@value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-gcc-<VERSION>-<RPM>.<ARCH>.rpm \
@value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-newlib-<VERSION>-<RPM>.<ARCH>.rpm \
@value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-libgcc-<VERSION>-<RPM>.<ARCH>.rpm \
@value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-gcc-c++-<VERSION>-<RPM>.<ARCH>.rpm \
@value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-libstd++-<VERSION>-<RPM>.<ARCH>.rpm
@end example
@b{NOTE}: Some targets do not support building all languages.
@b{NOTE}: It may be necessary to remove the build tree in the
@code{BUILD} directory under the RPM root directory.
@c
@c Building the GDB using RPM
@c
@subsection Building the 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
rpm -U @value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-gdb-<VERSION>-<RPM_RELEASE>.src.rpm
@end example
@example
cd <RPM_ROOT_DIRECTORY>/SPECS
rpm -bb i386-rtems@value{RTEMSAPI}-gdb-<VERSION>.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
@value{RTEMSRPMPREFIX}gdb-common-<VERSION>-<RPM_RELEASE>.<ARCH>.rpm
@value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-gdb-<VERSION>-<RPM_RELEASE>.<ARCH>.rpm
@end example
@b{NOTE}: It may be necessary to remove the build tree in the
@code{BUILD} directory under the RPM root directory.
@c
@c Common Problems
@c
@section Common Problems
@subsection Error Message Indicates Invalid Option to Assembler
If a message like this is printed then the new cross compiler
is most likely using the native assembler instead of the cross
assembler or vice-versa (native compiler using new cross assembler).
This can occur for one of the following reasons:
@itemize @bullet
@item Binutils Patch Improperly Applied
@item Binutils Not Built
@item Current Directory is in Your PATH
@end itemize
If you are using binutils 2.9.1 or newer with certain older versions of
gcc, they do not agree on what the name of the newly
generated cross assembler is. Older binutils called it @code{as.new}
which became @code{as.new.exe} under Windows. This is not a valid
file name, so @code{as.new} is now called @code{as-new}. By using the latest
released tool versions and RTEMS patches, this problem will be avoided.
If binutils did not successfully build the cross assembler, then
the new cross gcc (@code{xgcc}) used to build the libraries can not
find it. Make sure the build of the binutils succeeded.
If you include the current directory in your PATH, then there
is a chance that the native compiler will accidentally use
the new cross assembler instead of the native one. This usually
indicates that "." is before the standard system directories
in your PATH. As a general rule, including "." in your PATH
is a security risk and should be avoided. Remove "." from
your PATH.
@b{NOTE}: In some environments, it may be difficult to remove "."
completely from your PATH. In this case, make sure that "."
is after the system directories containing "as" and "ld".
@subsection Error Messages Indicating Configuration Problems
If you see error messages like the following,
@itemize @bullet
@item cannot configure libiberty
@item coff-emulation not found
@item etc.
@end itemize
Then it is likely that one or more of your gnu tools is
already configured locally in its source tree. You can check
for this by searching for the @code{config.status} file
in the various tool source trees. The following command
does this for the binutils source:
@example
find binutils-<VERSION> -name config.status -print
@end example
The solution for this is to execute the command
@code{make distclean} in each of the GNU tools
root source directory. This should remove all
generated files including Makefiles.
This situation usually occurs when you have previously
built the tool source for some non-RTEMS target. The
generated configuration specific files are still in
the source tree and the include path specified during
the RTEMS build accidentally picks up the previous
configuration. The include path used is something like
this:
@example
-I../../binutils-<VERSION>/gcc -I/binutils-<VERSION>/gcc/include -I.
@end example
Note that the tool source directory is searched before the
build directory.
This situation can be avoided entirely by never using
the source tree as the build directory.

28
doc/started/buildrt.t
View File

@@ -5,6 +5,11 @@
@chapter Building RTEMS
@b{NOTE}: If you built your toolset with RSB, by default the RSB also
builds RTEMS while building the compiler toolset. You may already have
a built and installed RTEMS in this case, and if not you should check
the RSB documentation at @uref{https://docs.rtems.org/rsb/,https://docs.rtems.org/rsb/}.
@section Obtain the RTEMS Source Code
This section provides pointers to the RTEMS source code and example
@@ -14,8 +19,8 @@ directory whose name is the release on the ftp site. The RTEMS ftp site
is accessible via both the ftp and http protocols at the following URLs:
@itemize @bullet
@item @uref{http://www.rtems.org/ftp/pub/rtems,http://www.rtems.org/ftp/pub/rtems}
@item @uref{ftp://www.rtems.org/pub/rtems,ftp://www.rtems.org/pub/rtems}
@item @uref{http://ftp.rtems.org/pub/rtems,http://ftp.rtems.org/pub/rtems}
@item @uref{ftp://ftp.rtems.org/pub/rtems,ftp://ftp.rtems.org/pub/rtems}
@end itemize
Associated with each RTEMS Release is a set of example programs.
@@ -47,7 +52,7 @@ Instead of downloading release tarballs you may choose to check out the current
RTEMS source from the project's source code repository. For details on
accessing the RTEMS source repository consult:
@uref{http://wiki.rtems.org/wiki/index.php/RTEMS_GIT_Repository, http://wiki.rtems.org/wiki/index.php/RTEMS_GIT_Repository}.
@uref{https://devel.rtems.org/wiki/Developer/Git,https://devel.rtems.org/wiki/Developer/Git}.
@section Add <INSTALL_POINT>/bin to Executable PATH
@@ -56,8 +61,8 @@ in your search path. It is important to have the RTEMS toolset first
in your path to ensure that you are using the intended version of all
tools. The following command prepends the directory where
the tools were installed in a previous step. If you are using
binaries provided by the RTEMS Project, the <INSTALL_POINT> will be
@code{/opt/rtems-@value{RTEMSAPI}}
binaries installed to @code{/opt/rtems-@value{RTEMSAPI}}, then the
<INSTALL_POINT> will be @code{/opt/rtems-@value{RTEMSAPI}}
@example
export PATH=<INSTALL_POINT>/bin:$@{PATH@}
@@ -106,11 +111,9 @@ m68k-rtems@code{RTEMSAPI}-gcc -v -c f.c
@end example
If this produces messages that indicate the assembly code is not valid,
then it is likely that you have fallen victim to one of the problems
described in @ref{Error Message Indicates Invalid Option to Assembler}
Please do not feel bad about this and do not give up, one of the most
common installation errors is for the cross-compiler not to be able
to find the cross assembler and default to using the native @code{as}.
then it is likely that you have fallen victim to one of the most
common installation errors and the cross-compiler is not able
to find the cross assembler and defaults to using the native @code{as}.
This can result in very confusing error messages.
@section Building RTEMS for a Specific Target and BSP
@@ -162,8 +165,9 @@ the @code{BOARD_SUPPORT_PACKAGE} board.
@example
mkdir build-rtems
cd build-rtems
../rtems-@value{RTEMSAPI}.VERSION/configure --target=<TARGET_CONFIGURATION> \
--disable-posix --disable-networking --disable-cxx \
../rtems-@value{RTEMSAPI}.VERSION/configure \
--target=<TARGET_CONFIGURATION> \
--disable-networking \
--enable-rtemsbsp=<BSP>\
--prefix=<INSTALL_POINT>
make all

37
doc/started/intro.t
View File

@@ -136,37 +136,24 @@ The RTEMS Project provides formatted documentation for the primary
tools in the cross development toolset including BINUTILS, GCC,
NEWLIB, and GDB with the pre-built versions of those tools.
Much of the documentation is available at other sites on the Internet.
The following is a list of URLs where one can find HTML versions of
the GNU manuals:
Much of the documentation is available at other sites on the Internet,
for example the GNU manuals are hosted by the Free Software Foundation
at @uref{http://www.gnu.org/manual/manual.html, http://www.gnu.org/manual/manual.html}.
@table @b
@item Free Software Foundation
@uref{http://www.gnu.org/manual/manual.html,
http://www.gnu.org/manual/manual.html}
@item Delorie Software
@uref{http://www.delorie.com/gnu/docs, http://www.delorie.com/gnu/docs}
@end table
@subsection RTEMS Mailing List
@subsection RTEMS Mailing Lists
@uref{mailto:@value{RTEMSUSERS},@value{RTEMSUSERS}}
This is the primary mailing list for the discussion of issues
related to RTEMS, including GNAT/RTEMS. If you have questions
about RTEMS, wish to make suggestions, track development efforts,
or just want to pick up hints, this is a good list to monitor.
The users mailing list is for any and all questions about RTEMS, especially
those focusing on how to use RTEMS.
If you would like to browse the thousands of messages in the fifteen
year archive of the mailing list or subscribe to it, please visit
@uref{http://www.rtems.org/mailman,http://www.rtems.org/mailman} for
@uref{https://lists.rtems.org/mailman/listinfo/users,https://lists.rtems.org/mailman/listinfo/users} for
more information,
@subsection GCC Mailing Lists
@uref{mailto:@value{RTEMSDEVEL},@value{RTEMSDEVEL}}
The devel mailing list is the place to track ongoing RTEMS development
and to discuss changes to RTEMS. This list is also where patches are
submitted.
The GCC Project is hosted at @uref{http://gcc.gnu.org,http://gcc.gnu.org}.
They maintain multiple mailing lists that are described at the web site
along with subscription information.

7
doc/started/require.t
View File

@@ -152,10 +152,3 @@ to at least GNU fileutils version 3.16 to resolve this problem.
@end itemize
@subsection GNU/Linux Distributions using Debian Packaging Format
The RTEMS Project does not currently provide prebuilt toolsets in the Debian packaging format used by the Debian and Ubuntu distributions. If you are using a distribution using this packaging format, then you have two options for installing the RTEMS toolset.
The first option is to build the toolset from source following the instructions in the @ref{Building the GNU Cross Compiler Toolset}. This is an approach taken by many users.
Alternatively, it is often possible to extract the contents of the RPM files which contain the portions of the toolset you require. In this case, you will follow the instructions in @ref{Locating the RPMs for your GNU/Linux Distribution} but assume your distribution is the RedHat Enterprise Linux version which is closest to yours from a shared library perspective. As of December 2010, this is usually RedHat Enterprise Linux version 5. As time passes, it is expected that version 6 will be appropriate in more cases. You will extract the contents of these RPM files using either @code{rpm2cpio} and install them or you may be able to use the @code{alien} tool to convert them to Debian packaging.

4
doc/started/started.texi
View File

@@ -64,8 +64,7 @@ This is the online version of the Getting Started with RTEMS.
@menu
* Introduction::
* Requirements::
* Prebuilt Toolset Executables::
* Building the GNU Cross Compiler Toolset::
* Building the GNU Cross Compiler Toolset with RSB::
* Building RTEMS::
* Building the Sample Applications::
* Where To Go From Here::
@@ -77,7 +76,6 @@ This is the online version of the Getting Started with RTEMS.
@include intro.texi
@include require.texi
@include binaries.texi
@include buildc.texi
@include buildrt.texi
@include sample.texi