Index: doc/source-builder.txt
===================================================================
--- doc/source-builder.txt	(revision 4351cf4d7fe6d3727af79675e1b7a4ed90b6f186)
+++ doc/source-builder.txt	(revision 69f9806cc1dc2d1b71c0c6ed5bd47003f8bc681e)
@@ -125,5 +125,5 @@
 are detected. Locate those executable files and install them. You may also be
 given a list of warnings about executable files not in the expected location
-how-ever the executable was located somewhere in your environment's path. You
+however the executable was located somewhere in your environment's path. You
 will need to check each tool to determine if this is an issue. An executable
 not in the standard location may indicate it is not the host operating system's
@@ -229,7 +229,7 @@
 <6> Unstable tool sets are used by RTEMS developers to test new tool sets. You
     are welcome to try them but you must remember they are unstable, can change
-    at point in time and your application may not work. If you have an issue
-    with a production tool it may pay to try the unstable tool to see if it has
-    been resolved.
+    at any point in time and your application may not work. If you have an
+    issue with a production tool it may pay to try the unstable tool to see if
+    it has been resolved.
 
 Building
@@ -348,4 +348,10 @@
     executable back to the original source used to build it.
 
+NOTE: The RTEMS thread model enables specific hooks in GCC so applications
+built with RTEMS tools need the RTEMS runtime to operate correctly. You can use
+RTEMS tools to build bare metal component but it is more difficult than with a
+bare metal tool chain and you need to know what you are doing at a low
+level. The RTEMS Source Builder can build bare metal tool chains.
+
 Installing and Tar Files
 ~~~~~~~~~~~~~~~~~~~~~~~~
@@ -356,12 +362,22 @@
 source will be downloaded, built, installed and cleaned up.
 
-The tar files are created with the full build prefix present. This can cause
+The tar files are created with the full build prefix present and if you follow
+the examples given in this documentation the path is absolute. This can cause
 problems if you are installing on a host you do not have super user or
-administrator rights on if the prefix path references part you do not have
-write access t0o. You can use the +--strip-components+ option in tar if your
-tar file supports it to remove the parts you do not have write access too or
-you may need to unpack the tar file somewhere and copy the file tree from the
-level you have write access from. Embedding the full prefix path in the tar
-files lets you know what the prefix is.
+administrator rights on because the prefix path may references part you do not
+have write access too and tar will not extract the files. You can use the
++--strip-components+ option in tar if your host tar application supports it to
+remove the parts you do not have write access too or you may need to unpack the
+tar file somewhere and copy the file tree from the level you have write access
+from. Embedding the full prefix path in the tar files lets you know what the
+prefix is and is recommended. For example if
+`/home/chris/development/rtems/4.11` is the prefix used you cannot
+change directory to the root (`/`) and install because the `/home` is root
+access only. To install you would:
+
+-------------------------------------------------------------
+$ cd
+$ tar --strip-components=3 -xjf rtems-4.11-sparc-rtems4.11-1.tar.bz2
+-------------------------------------------------------------
 
 A build set tar file is created by adding `--bset-tar-file` option to the
@@ -495,5 +511,5 @@
 flexibility open source gives you. Fast moving host environments are
 fantastic. We have powerful multi-core computers with huge amounts of memory
-and state of the art operating systems to run on them how-ever the product or
+and state of the art operating systems to run on them however the product or
 project you are part of may need to be maintained well past the life time of
 these host. Being able to build from source an important and critical part of
@@ -509,5 +525,5 @@
 any change in the host's configuration may effect you. The changes the host's
 package management system makes may be perfectly reasonable in relation to the
-distribution being managed how-ever this may not extend to you and your
+distribution being managed however this may not extend to you and your
 tools. Building your tools from source and controlling the specific version of
 these dependent parts means you are not exposing yourself to unexpected and
@@ -533,5 +549,5 @@
 
 The RTEMS Source Builder is a Python program and every care is taken to test
-the code how-ever bugs, crashes, and build failure can and do happen. If you
+the code however bugs, crashes, and build failure can and do happen. If you
 find a bug please report it via the RTEMS Bug tracker tool Bugzilla:
 
@@ -832,5 +848,5 @@
 Configuration files specify how to build a package. Configuration files are
 scripts and have a +.cfg+ file extension. The script format is based loosely on
-the RPM spec file format how-ever the use and purpose in this tool does not
+the RPM spec file format however the use and purpose in this tool does not
 compare with the functionality and therefore the important features of the spec
 format RPM needs and uses.
@@ -1164,7 +1180,7 @@
 The +%version% macro sets the version the package. If the package is a single
 component it tracks that component's version number. For example in the
-_libusb_ configuration the +%version+ is the same as +%libusb_version+,
-how-ever in a GCC with Newlib configuration there is no single version
-number. In this case the GCC version is used.
+_libusb_ configuration the +%version+ is the same as +%libusb_version+, however
+in a GCC with Newlib configuration there is no single version number. In this
+case the GCC version is used.
 
 -------------------------------------------------------------
@@ -1482,8 +1498,8 @@
 large number of architectures RTEMS supports can make it difficult to get a
 common stable version of all the packages. An architecture may require a recent
-GCC because an existing bug has been fixed, how-ever the more recent version
-may have a bug in other architecture. Architecture specific patches should be
+GCC because an existing bug has been fixed, however the more recent version may
+have a bug in other architecture. Architecture specific patches should be
 limited to the architecture it relates to. The patch may fix a problem on the
-effect architecture how-ever it could introduce a problem in another
+effect architecture however it could introduce a problem in another
 architecture. Limit exposure limits any possible crosstalk between
 architectures.
@@ -1644,15 +1660,15 @@
 fail to build. It keeps the disk usage down.
 +--jobs+;;
-Control the number of jobs make is given. The jobs can 'none' for only 1 job,
-'half' so the number of jobs is half the number of detected cores, a fraction
-such as '0.25' so the number of jobs is a quarter of the number of detected
-cores and a number such as '25' which forces the number of jobs to that
-number.
+Control the number of jobs make is given. The jobs can be 'none' for only 1
+job, 'half' so the number of jobs is half the number of detected cores, a
+fraction such as '0.25' so the number of jobs is a quarter of the number of
+detected cores and a number such as '25' which forces the number of jobs to
+that number.
 +--host+;;
-Set the host triplet value. Becareful with this option.
+Set the host triplet value. Be careful with this option.
 +--build+;;
-Set the build triplet. Becareful with this option.
+Set the build triplet. Be careful with this option.
 +--target+;;
-Set the target triplet. Becareful with this option. This is useful if you have
+Set the target triplet. Be careful with this option. This is useful if you have
 a generic configuration script that can work for a range of architectures.
 +--prefix path+;;
@@ -1845,5 +1861,5 @@
 libraries or emulation layer to run once built. The tools understand and use
 standard Windows paths and integrate easly into Windows IDE environments. A
-shell maybe needed to build other parts of your system how-ever if your
+shell maybe needed to build other parts of your system however if your
 development tools are all native Windows tool you can easly integrate these
 tool sets.
@@ -1993,10 +2009,10 @@
 had either spec files, RPM files or SRPM files. The RPM and SPRM files where
 useless because you needed an 'rpm' type tool to extract and manage them. There
-are versions of 'rpm' for a number of non-RPM hosts how-ever these proved to be
-in various broken states and random-ally maintained. The solution I settled on
-was to use spec files so I wrote a Python based tool that parsed the spec file
+are versions of 'rpm' for a number of non-RPM hosts however these proved to be
+in various broken states and randomly maintained. The solution I settled on was
+to use spec files so I wrote a Python based tool that parsed the spec file
 format and allowed me to create a shell script I could run to build the
 package. This approach proved successful and I was able to track the RPM
-version of the RTEMS tools on a non-RPM host over a number of years. How-ever
+version of the RTEMS tools on a non-RPM host over a number of years. however
 the SpecBuilder tool did not help me build tools or other packages not related
 to the RTEMS project where there was no spec file I could use so I needed
