[PATCH] libgloss: fix typo in porting doc

[Mike Frysinger]

i noticed a typo in the porting doc:
-Libgloss's creation was forced initially be the cpu32 processor
+Libgloss's creation was forced initially because of the cpu32 processor

but fixing this seems like the whole paragraph needs to be reformatted due to 
long lines.  am i doing this right ?  i rarely touch texi files, so i dont 
really know the policy on them ...
-mike

--- libgloss/doc/porting.texi	19 Jun 2009 18:18:01 -0000	1.3
+++ libgloss/doc/porting.texi	22 Sep 2010 23:30:18 -0000
@@ -106,16 +106,16 @@ execution environment. An example of thi
 AMD 29k processor family. All of the execution environments for this
 processor are have the same interface, the same memory map, and the same
 I/O code. In this case all of the support code is in newlib/sys/FIXME.
-Libgloss's creation was forced initially be the @code{cpu32} processor
-family. There are many different execution environments for this line,
-and they vary wildly. newlib itself has only has a few dependencies that
-it needs for each target. These are explained later in this doc. The
-hardware dependent part of newlib was reorganized into a separate
-directory structure within newlib called the stub dirs. It was initially
-called this because most of the routines newlib needs for a target were
-simple stubs that do nothing, but return a value to the application. They
-only exist so the linker can produce a final executable image. This work
-was done during the early part of 1993.
+Libgloss's creation was forced initially because of the @code{cpu32}
+processor family. There are many different execution environments for
+this line, and they vary wildly. newlib itself has only has a few
+dependencies that it needs for each target. These are explained later in
+this doc. The hardware dependent part of newlib was reorganized into a
+separate directory structure within newlib called the stub dirs. It was
+initially called this because most of the routines newlib needs for a
+target were simple stubs that do nothing, but return a value to the
+application. They only exist so the linker can produce a final
+executable image. This work was done during the early part of 1993.
 
 After a while it became apparent that this approach of isolating the
 hardware and systems files together made sense. Around this same time