misc: fix more typos here and there...
author"Antony N. Pavlov" <antony@niisi.msk.ru>
Sun Jul 17 16:53:40 2011 +0200 (2011-07-17)
changeset 25645d4e91c0343e
parent 2563 e17f35b05539
child 2565 fbc2b9d638ec
misc: fix more typos here and there...

Reported-by: "Antony N. Pavlov" <antony@niisi.msk.ru>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
TODO
config/binutils.in
config/cc.in
config/global/download.in
config/global/extract.in
config/global/paths.in
config/libc/glibc-eglibc.in-common
config/target.in
config/toolchain.in
docs/1 - Introduction.txt
docs/2 - Installing crosstool-NG.txt
docs/3 - Configuring a toolchain.txt
docs/4 - Building the toolchain.txt
docs/5 - Using the toolchain.txt
docs/6 - Toolchain types.txt
docs/8 - Internals.txt
docs/9 - How is a toolchain constructed.txt
docs/B - Known issues.txt
docs/C - Misc. tutorials.txt
docs/ct-ng.1.in
kconfig/kconfig.mk
scripts/crosstool-NG.sh.in
scripts/patch-rework.sh
scripts/populate.in
scripts/showSamples.sh
     1.1 --- a/TODO	Sun Jul 17 16:54:50 2011 +0200
     1.2 +++ b/TODO	Sun Jul 17 16:53:40 2011 +0200
     1.3 @@ -1,6 +1,6 @@
     1.4  This is a somewhat ordered TODO list:
     1.5  
     1.6 -Recuring tasks:
     1.7 +Recurring tasks:
     1.8  
     1.9  - update versions for every tools...
    1.10  
     2.1 --- a/config/binutils.in	Sun Jul 17 16:54:50 2011 +0200
     2.2 +++ b/config/binutils.in	Sun Jul 17 16:53:40 2011 +0200
     2.3 @@ -12,7 +12,7 @@
     2.4      bool
     2.5      prompt "ELF"
     2.6      help
     2.7 -      This will make your system build ELF exectubales,
     2.8 +      This will make your system build ELF executables,
     2.9        suitable for architectures with an MMU.
    2.10  
    2.11  endif # ARCH_USE_MMU
     3.1 --- a/config/cc.in	Sun Jul 17 16:54:50 2011 +0200
     3.2 +++ b/config/cc.in	Sun Jul 17 16:53:40 2011 +0200
     3.3 @@ -104,7 +104,7 @@
     3.4        Enter here a comma-separated list of languages that you know your compiler
     3.5        supports, besides those listed above.
     3.6  
     3.7 -      Eg. gcc-4.1+ has a toy programming language, treelang. As it is not usefull
     3.8 +      Eg. gcc-4.1+ has a toy programming language, treelang. As it is not useful
     3.9        in real life, it is not available in the selection above.
    3.10  
    3.11  endif # ! BARE_METAL
     4.1 --- a/config/global/download.in	Sun Jul 17 16:54:50 2011 +0200
     4.2 +++ b/config/global/download.in	Sun Jul 17 16:53:40 2011 +0200
     4.3 @@ -23,7 +23,7 @@
     4.4      help
     4.5        Force downloading tarballs, even if one already exists.
     4.6        
     4.7 -      Usefull if you suspect a tarball to be damaged.
     4.8 +      Useful if you suspect a tarball to be damaged.
     4.9  
    4.10  config USE_MIRROR
    4.11      bool
    4.12 @@ -43,7 +43,7 @@
    4.13      bool
    4.14      prompt "Prefer the mirror"
    4.15      help
    4.16 -      Say 'Y' here if you prefer the LAN miror over the upstream sources.
    4.17 +      Say 'Y' here if you prefer the LAN mirror over the upstream sources.
    4.18  
    4.19  config MIRROR_BASE_URL
    4.20      string
    4.21 @@ -93,6 +93,6 @@
    4.22      help
    4.23        Only download the tarballs. Exit once it done.
    4.24        
    4.25 -      Usefull to pre-retrieve the tarballs before going off-line.
    4.26 +      Useful to pre-retrieve the tarballs before going off-line.
    4.27  
    4.28  endif # ! FORBID_DOWNLOAD
     5.1 --- a/config/global/extract.in	Sun Jul 17 16:54:50 2011 +0200
     5.2 +++ b/config/global/extract.in	Sun Jul 17 16:53:40 2011 +0200
     5.3 @@ -6,9 +6,9 @@
     5.4      bool
     5.5      prompt "Force extractions"
     5.6      help
     5.7 -      Force extraction of already exctracted tarballs.
     5.8 +      Force extraction of already extracted tarballs.
     5.9        
    5.10 -      Usefull if you suspect a previous extract did not complete (eg. broken
    5.11 +      Useful if you suspect a previous extract did not complete (eg. broken
    5.12        tarball), or you added a new set of patches for this component.
    5.13  
    5.14  config OVERIDE_CONFIG_GUESS_SUB
    5.15 @@ -37,7 +37,7 @@
    5.16      help
    5.17        Exit after unpacking and patching tarballs.
    5.18        
    5.19 -      Usefull to look at the code before doing the build itself.
    5.20 +      Useful to look at the code before doing the build itself.
    5.21  
    5.22  choice
    5.23      prompt "Patches origin"
    5.24 @@ -97,7 +97,7 @@
    5.25      help
    5.26        Don't use any patch at all.
    5.27        
    5.28 -      Please be carefull if you select this. Most components do require
    5.29 +      Please be careful if you select this. Most components do require
    5.30        patches to properly build. It can happen, however, that support for
    5.31        your architecture is clean enough that you can build a toolchain
    5.32        with no patch. But most probably, this is *not* the case.
    5.33 @@ -128,5 +128,5 @@
    5.34      help
    5.35        Enter the custom patch directory here.
    5.36        
    5.37 -      Note that you must ensure that the directory contianing your custom
    5.38 +      Note that you must ensure that the directory containing your custom
    5.39        patches is arranged the same way the official directory is.
     6.1 --- a/config/global/paths.in	Sun Jul 17 16:54:50 2011 +0200
     6.2 +++ b/config/global/paths.in	Sun Jul 17 16:53:40 2011 +0200
     6.3 @@ -69,12 +69,12 @@
     6.4        If you say 'y' here, then PREFIX_DIR (above) will be eradicated
     6.5        prior to the toolchain is built.
     6.6        
     6.7 -      This can be usefull when you are trying different settings (due
     6.8 +      This can be useful when you are trying different settings (due
     6.9        to build failures or feature tests). In this case, to avoid using
    6.10        a potentially broken previous toolchain, the install location is
    6.11        removed, to start afresh.
    6.12        
    6.13 -      On the oher hand, if you are building a final toolchain, and install
    6.14 +      On the other hand, if you are building a final toolchain, and install
    6.15        it into a directory with pre-install, unrelated programs, it would be
    6.16        damageable to remove that directory. In this case, you may want to
    6.17        say 'n' here.
    6.18 @@ -98,7 +98,7 @@
    6.19        Render the directory of the toolchain (and its sub-directories)
    6.20        read-only.
    6.21        
    6.22 -      Usefull for toolchains destined for production.
    6.23 +      Useful for toolchains destined for production.
    6.24  
    6.25  config STRIP_ALL_TOOLCHAIN_EXECUTABLES
    6.26      bool
     7.1 --- a/config/libc/glibc-eglibc.in-common	Sun Jul 17 16:54:50 2011 +0200
     7.2 +++ b/config/libc/glibc-eglibc.in-common	Sun Jul 17 16:53:40 2011 +0200
     7.3 @@ -158,7 +158,7 @@
     7.4        Let ./configure decide what minimum kernel version glibc/eglibc
     7.5        will be able to run against.
     7.6        
     7.7 -      This will inclde legacy compatibility code for older kernels in
     7.8 +      This will include legacy compatibility code for older kernels in
     7.9        the C library, thus ensuring that it will run on a large number
    7.10        of old kernels.
    7.11        
    7.12 @@ -173,7 +173,7 @@
    7.13      bool
    7.14      prompt "Same as kernel headers (default)"
    7.15      help
    7.16 -      Normaly, you'll want glibc/eglibc to run against the same kernel
    7.17 +      Normally, you'll want glibc/eglibc to run against the same kernel
    7.18        version as the one used for the headers.
    7.19        
    7.20        This is the default.
     8.1 --- a/config/target.in	Sun Jul 17 16:54:50 2011 +0200
     8.2 +++ b/config/target.in	Sun Jul 17 16:53:40 2011 +0200
     8.3 @@ -178,7 +178,7 @@
     8.4        Pick a value from the gcc manual for your choosen gcc version and your
     8.5        target CPU.
     8.6  
     8.7 -      Leave blank if you don't know, or if your target architecutre does not
     8.8 +      Leave blank if you don't know, or if your target architecture does not
     8.9        offer this option.
    8.10  
    8.11  config ARCH_CPU
    8.12 @@ -282,7 +282,7 @@
    8.13        that will run on the target (eg. libc.so).
    8.14        
    8.15        Note that the options above for ARCH, ABI, CPU, TUNE and FPU will be
    8.16 -      automaticaly used. You don't need to specify them here.
    8.17 +      automatically used. You don't need to specify them here.
    8.18        
    8.19        Leave blank if you don't know better.
    8.20  
     9.1 --- a/config/toolchain.in	Sun Jul 17 16:54:50 2011 +0200
     9.2 +++ b/config/toolchain.in	Sun Jul 17 16:53:40 2011 +0200
     9.3 @@ -27,7 +27,7 @@
     9.4        is 'sysroot' (the default) or 'sys-root'.
     9.5        
     9.6        You are free to enter anything here, except for spaces, and '/'
     9.7 -      (see SYSROOT_DIR_PREFIX, below). If you leave this empy, then the
     9.8 +      (see SYSROOT_DIR_PREFIX, below). If you leave this empty, then the
     9.9        default 'sysroot' is used.
    9.10  
    9.11  config SYSROOT_DIR_PREFIX
    9.12 @@ -37,7 +37,7 @@
    9.13      default ""
    9.14      help
    9.15        *
    9.16 -      * Unless you realy know you need that, leave it empty!
    9.17 +      * Unless you really know you need that, leave it empty!
    9.18        *
    9.19        
    9.20        This string will be interpreted as a directory component to be added
    9.21 @@ -65,7 +65,7 @@
    9.22        
    9.23        If you wish to move the toolchain to another host, and you are not
    9.24        confident that this host has the required versions of system libs, then
    9.25 -      you can say 'Y' here, and all the host tools will be linked staticaly.
    9.26 +      you can say 'Y' here, and all the host tools will be linked statically.
    9.27        
    9.28        The impacted tools are:
    9.29          - the GNU binutils
    9.30 @@ -121,7 +121,7 @@
    9.31      prompt "Tuple's sed transform"
    9.32      default ""
    9.33      help
    9.34 -      Normaly, you'd call your toolchain components (especially gcc) by
    9.35 +      Normally, you'd call your toolchain components (especially gcc) by
    9.36        prefixing the target tuple followed by a dash and the component name
    9.37        (eg. armeb-unknown-linux-uclibc-gcc).
    9.38        
    9.39 @@ -140,7 +140,7 @@
    9.40      prompt "Tuple's alias"
    9.41      default ""
    9.42      help
    9.43 -      Normaly, you'd call your toolchain components (especially gcc) by
    9.44 +      Normally, you'd call your toolchain components (especially gcc) by
    9.45        prefixing the target tuple followed by a dash and the component name
    9.46        (eg. armeb-unknown-linux-uclibc-gcc).
    9.47        
    10.1 --- a/docs/1 - Introduction.txt	Sun Jul 17 16:54:50 2011 +0200
    10.2 +++ b/docs/1 - Introduction.txt	Sun Jul 17 16:53:40 2011 +0200
    10.3 @@ -71,7 +71,7 @@
    10.4  So I decided to clean up crosstool in the state it was, re-order the things
    10.5  in place, add appropriate support for what I needed, that is uClibc support
    10.6  and a menu-driven configuration, named the new implementation crosstool-NG,
    10.7 -(standing for crosstool Next Generation, as many other comunity projects do,
    10.8 +(standing for crosstool Next Generation, as many other community projects do,
    10.9  and as a wink at the TV series "Star Trek: The Next Generation" ;-) ) and
   10.10  made it available to the community, in case it was of interest to any one.
   10.11  
    11.1 --- a/docs/2 - Installing crosstool-NG.txt	Sun Jul 17 16:54:50 2011 +0200
    11.2 +++ b/docs/2 - Installing crosstool-NG.txt	Sun Jul 17 16:53:40 2011 +0200
    11.3 @@ -13,7 +13,7 @@
    11.4   - or only build it and run from the source directory.
    11.5  
    11.6  The former should be used if you got crosstool-NG from a packaged tarball, see
    11.7 -"Install method", below, while the latter is most useful for developpers that
    11.8 +"Install method", below, while the latter is most useful for developers that
    11.9  use a clone of the repository, and want to submit patches, see "The Hacker's
   11.10  way", below.
   11.11  
   11.12 @@ -50,7 +50,7 @@
   11.13  See below for complete usage.
   11.14  
   11.15  Now, provided you used a clone of the repository, you can send me your changes.
   11.16 -See the section titled CONTRIBUTING, below, for how to submit changees.
   11.17 +See the section titled CONTRIBUTING, below, for how to submit changes.
   11.18  
   11.19  
   11.20  Preparing for packaging |
   11.21 @@ -82,12 +82,12 @@
   11.22  Contributed code |
   11.23  -----------------+
   11.24  
   11.25 -Some people contibuted code that couldn't get merged for various reasons. This
   11.26 +Some people contributed code that couldn't get merged for various reasons. This
   11.27  code is available as lzma-compressed patches, in the contrib/ sub-directory.
   11.28  These patches are to be applied to the source of crosstool-NG, prior to
   11.29  installing, using something like the following:
   11.30    lzcat contrib/foobar.patch.lzma |patch -p1
   11.31  
   11.32 -There is no guarantee that a particuliar contribution applies to the current
   11.33 +There is no guarantee that a particular contribution applies to the current
   11.34  version of crosstool-ng, or that it will work at all. Use contributions at
   11.35  your own risk.
    12.1 --- a/docs/3 - Configuring a toolchain.txt	Sun Jul 17 16:54:50 2011 +0200
    12.2 +++ b/docs/3 - Configuring a toolchain.txt	Sun Jul 17 16:53:40 2011 +0200
    12.3 @@ -8,7 +8,7 @@
    12.4  _________________________/
    12.5  
    12.6  
    12.7 -crosstool-NG is configured with a configurator presenting a menu-stuctured set
    12.8 +crosstool-NG is configured with a configurator presenting a menu-structured set
    12.9  of options. These options let you specify the way you want your toolchain
   12.10  built, where you want it installed, what architecture and specific processor it
   12.11  will support, the version of the components you want to use, etc... The
   12.12 @@ -50,7 +50,7 @@
   12.13  ---------------------------+
   12.14  
   12.15  CT_LOCAL_TARBALLS_DIR:
   12.16 -  If you already have some tarballs in a direcotry, enter it here. That will
   12.17 +  If you already have some tarballs in a directory, enter it here. That will
   12.18    speed up the retrieving phase, where crosstool-NG would otherwise download
   12.19    those tarballs.
   12.20  
   12.21 @@ -67,7 +67,7 @@
   12.22    Avoid dots, commas, and special characters.
   12.23  
   12.24  CT_TARGET_ALIAS:
   12.25 -  An alias for the toolchian. It will be used as a prefix to the toolchain
   12.26 +  An alias for the toolchain. It will be used as a prefix to the toolchain
   12.27    tools. For example, you will have ${CT_TARGET_ALIAS}-gcc
   12.28  
   12.29  Also, if you think you don't see enough versions, you can try to enable one of
    13.1 --- a/docs/4 - Building the toolchain.txt	Sun Jul 17 16:54:50 2011 +0200
    13.2 +++ b/docs/4 - Building the toolchain.txt	Sun Jul 17 16:53:40 2011 +0200
    13.3 @@ -129,7 +129,7 @@
    13.4  that it does not work on host systems that lack a shell, for example the
    13.5  MingW32 environment. To solve the issue, the wrapper has been re-written in C,
    13.6  and compiled at build time. This C wrapper is much more complex than the shell
    13.7 -script, and although it sems to be working, it's been only lightly tested.
    13.8 +script, and although it seems to be working, it's been only lightly tested.
    13.9  Some of the expected short-comings with this C wrapper are;
   13.10   - multi-byte file names may not be handled correctly
   13.11   - it's really big for what it does
    14.1 --- a/docs/5 - Using the toolchain.txt	Sun Jul 17 16:54:50 2011 +0200
    14.2 +++ b/docs/5 - Using the toolchain.txt	Sun Jul 17 16:53:40 2011 +0200
    14.3 @@ -41,7 +41,7 @@
    14.4    your-target-tuple-populate -s /your/root -d /your/root-populated
    14.5  
    14.6  This will copy /your/root into /your/root-populated, and put the needed and only
    14.7 -the needed libraries there. Thus you don't polute /your/root with any cruft that
    14.8 +the needed libraries there. Thus you don't pollute /your/root with any cruft that
    14.9  would no longer be needed should you have to remove stuff. /your/root always
   14.10  contains only those things you install in it.
   14.11  
    15.1 --- a/docs/6 - Toolchain types.txt	Sun Jul 17 16:54:50 2011 +0200
    15.2 +++ b/docs/6 - Toolchain types.txt	Sun Jul 17 16:53:40 2011 +0200
    15.3 @@ -30,7 +30,7 @@
    15.4  this as "2 and 2 are 4". Here is how they come into play:
    15.5  
    15.6  1) build == host == target
    15.7 -    This is a plain native toolchain, targetting the exact same machine as the
    15.8 +    This is a plain native toolchain, targeting the exact same machine as the
    15.9      one it is built on, and running again on this exact same machine. You have
   15.10      to build such a toolchain when you want to use an updated component, such
   15.11      as a newer gcc for example.
    16.1 --- a/docs/8 - Internals.txt	Sun Jul 17 16:54:50 2011 +0200
    16.2 +++ b/docs/8 - Internals.txt	Sun Jul 17 16:53:40 2011 +0200
    16.3 @@ -32,7 +32,7 @@
    16.4  that library directory.
    16.5  
    16.6  Because of a stupid make behavior/bug I was unable to track down, implicit make
    16.7 -rules are disabled: installing with --local would triger those rules, and mconf
    16.8 +rules are disabled: installing with --local would trigger those rules, and mconf
    16.9  was unbuildable.
   16.10  
   16.11  
   16.12 @@ -130,7 +130,7 @@
   16.13       - optional
   16.14       - the environment variable CT_TARGET_SYS
   16.15       - contains:
   16.16 -       the sytem part of the target tuple.
   16.17 +       the system part of the target tuple.
   16.18         Eg.: "gnu" for glibc on most architectures
   16.19              "gnueabi" for glibc on an ARM EABI
   16.20       - defaults to:
   16.21 @@ -159,7 +159,7 @@
   16.22         see above.
   16.23     + provides:
   16.24       - optional
   16.25 -     - the environement variables to configure the core and final compiler, specific to this architecture:
   16.26 +     - the environment variables to configure the core and final compiler, specific to this architecture:
   16.27         - CT_ARCH_CC_CORE_EXTRA_CONFIG   : additional, architecture specific core gcc ./configure flags
   16.28         - CT_ARCH_CC_EXTRA_CONFIG        : additional, architecture specific final gcc ./configure flags
   16.29       - default to:
    17.1 --- a/docs/9 - How is a toolchain constructed.txt	Sun Jul 17 16:54:50 2011 +0200
    17.2 +++ b/docs/9 - How is a toolchain constructed.txt	Sun Jul 17 16:53:40 2011 +0200
    17.3 @@ -50,13 +50,13 @@
    17.4  thereof, running on the target, we also need the C library. The C library
    17.5  provides a standard abstraction layer that performs basic tasks (such as
    17.6  allocating memory, printing output on a terminal, managing file access...).
    17.7 -There are many C libraries, each targetted to different systems. For the
    17.8 -Linux /desktop/, there is glibc or eglibc or ven uClibc, for embeded Linux,
    17.9 +There are many C libraries, each targeted to different systems. For the
   17.10 +Linux /desktop/, there is glibc or eglibc or even uClibc, for embedded Linux,
   17.11  you have a choice of eglibc or uClibc, while for system without an Operating
   17.12  System, you may use newlib, dietlibc, or even none at all. There a few other
   17.13 -C libraries, but they are not as widely used, and/or are targetted to very
   17.14 +C libraries, but they are not as widely used, and/or are targeted to very
   17.15  specific needs (eg. klibc is a very small subset of the C library aimed at
   17.16 -building contrained initial ramdisks).
   17.17 +building constrained initial ramdisks).
   17.18  
   17.19  Under Linux, the C library needs to know the API to the kernel to decide
   17.20  what features are present, and if needed, what emulation to include for
   17.21 @@ -168,7 +168,7 @@
   17.22      correct rounding, MPFR
   17.23    - the C library for the arithmetic of complex numbers, MPC
   17.24  
   17.25 -The dependencies for those liraries are:
   17.26 +The dependencies for those libraries are:
   17.27  
   17.28    - MPC requires GMP and MPFR
   17.29    - MPFR requires GMP
   17.30 @@ -205,7 +205,7 @@
   17.31  To enable LTO:
   17.32    - the ELF object file access library, libelf
   17.33  
   17.34 -The depencies for those libraries are:
   17.35 +The dependencies for those libraries are:
   17.36  
   17.37    - PPL requires GMP
   17.38    - CLooG/PPL requires GMP and PPL
   17.39 @@ -233,7 +233,7 @@
   17.40  So the list is complete. But why does crosstool-NG have more steps? |
   17.41  --------------------------------------------------------------------+
   17.42  
   17.43 -The already thirteen steps are the necessary steps, from a theorical point
   17.44 +The already thirteen steps are the necessary steps, from a theoretical point
   17.45  of view. In reality, though, there are small differences; there are three
   17.46  different reasons for the additional steps in crosstool-NG.
   17.47  
   17.48 @@ -249,9 +249,9 @@
   17.49  
   17.50  Third, crosstool-NG can also build some additional debug utilities to run on
   17.51  the target. This is where we build, for example, the cross-gdb, the gdbserver
   17.52 -and the native gdb (the last two run on the target, the furst runs on the
   17.53 +and the native gdb (the last two run on the target, the first runs on the
   17.54  same machine as the toolchain). The others (strace, ltrace, DUMA and dmalloc)
   17.55  are absolutely not related to the toolchain, but are nice-to-have stuff that
   17.56 -can greatly help when developping, so are included as goodies (and they are
   17.57 +can greatly help when developing, so are included as goodies (and they are
   17.58  quite easy to build, so it's OK; more complex stuff is not worth the effort
   17.59  to include in crosstool-NG).
    18.1 --- a/docs/B - Known issues.txt	Sun Jul 17 16:54:50 2011 +0200
    18.2 +++ b/docs/B - Known issues.txt	Sun Jul 17 16:53:40 2011 +0200
    18.3 @@ -7,7 +7,7 @@
    18.4  _____________/
    18.5  
    18.6  
    18.7 -This files lists the known issues encountered while developping crosstool-NG,
    18.8 +This files lists the known issues encountered while developing crosstool-NG,
    18.9  but that could not be addressed before the release.
   18.10  
   18.11  The file has one section for each known issue, each section containing four
   18.12 @@ -136,7 +136,7 @@
   18.13  Explanations:
   18.14    The gcc build procedure tries to run a Fortran test to see if it has a
   18.15    working native fortran compiler installed on the build machine, and it
   18.16 -  can't find one. A native Fortran compiler is needed (seems to be neede)
   18.17 +  can't find one. A native Fortran compiler is needed (seems to be needed)
   18.18    to build the Fortran frontend of the cross-compiler.
   18.19    Even if you don't want to build the Fortran frontend, gcc tries to see
   18.20    if it has one, but fails. This is no problem, as the Fortran frontend
    19.1 --- a/docs/C - Misc. tutorials.txt	Sun Jul 17 16:54:50 2011 +0200
    19.2 +++ b/docs/C - Misc. tutorials.txt	Sun Jul 17 16:53:40 2011 +0200
    19.3 @@ -275,7 +275,7 @@
    19.4  you should manually "hg qdelete" the patches that are already integrated upstream.
    19.5  
    19.6  
    19.7 -HOW TO FORMAT COMMIT MESSAGES (aka patch desciptions):
    19.8 +HOW TO FORMAT COMMIT MESSAGES (aka patch descriptions):
    19.9  
   19.10  Commit messages should look like (without leading pipes):
   19.11   |component: short, one-line description
    20.1 --- a/docs/ct-ng.1.in	Sun Jul 17 16:54:50 2011 +0200
    20.2 +++ b/docs/ct-ng.1.in	Sun Jul 17 16:53:40 2011 +0200
    20.3 @@ -99,7 +99,7 @@
    20.4  Builds a tarball of the generated toolchain, also saving the scripts from
    20.5  .B crosstool-NG
    20.6  that are needed to rebuild the target, and also saving the tarballs of the
    20.7 -componnents that were used.
    20.8 +components that were used.
    20.9  ."
   20.10  .SH ENVIRONMENT
   20.11  .TP
   20.12 @@ -107,7 +107,7 @@
   20.13  Respectively stops and restarts the build just before this step. To restart a
   20.14  step, a previous build should have run at least to that step, or further.
   20.15  
   20.16 -The list of steps is vailable with the action
   20.17 +The list of steps is viewable with the action
   20.18  .BR list-steps .
   20.19  ."
   20.20  .SH EXIT VALUE
    21.1 --- a/kconfig/kconfig.mk	Sun Jul 17 16:54:50 2011 +0200
    21.2 +++ b/kconfig/kconfig.mk	Sun Jul 17 16:53:40 2011 +0200
    21.3 @@ -129,7 +129,7 @@
    21.4  # Cheesy auto-dependencies
    21.5  # Only parse the following if a configurator was called, to avoid building
    21.6  # dependencies when not needed (eg. list-steps, list-samples...)
    21.7 -# We must be carefull what we enclose, because we need some of the variable
    21.8 +# We must be careful what we enclose, because we need some of the variable
    21.9  # definitions for clean (and distclean) at least.
   21.10  # Just protecting the "-include $(DEPS)" line should be sufficient.
   21.11  # And in case we want menuconfig, we have to check that lxdialog
   21.12 @@ -159,7 +159,7 @@
   21.13  
   21.14  # Each .o or .dep *can not* directly depend on kconfig/, because kconfig can
   21.15  # be touched during the build (who's touching it, btw?) so each .o or .dep
   21.16 -# would be re-built when it sould not be.
   21.17 +# would be re-built when it should not be.
   21.18  # So manually check for presence of $(obj) (ie. kconfig), and only mkdir
   21.19  # if needed. After all, that's not so bad...
   21.20  # mkdir $(obj)/lxdialog, because we need it, and incidentally, that
    22.1 --- a/scripts/crosstool-NG.sh.in	Sun Jul 17 16:54:50 2011 +0200
    22.2 +++ b/scripts/crosstool-NG.sh.in	Sun Jul 17 16:53:40 2011 +0200
    22.3 @@ -25,7 +25,7 @@
    22.4  . .config.2
    22.5  # Yes! We can do full logging from now on!
    22.6  
    22.7 -# Overide the locale early, in case we ever translate crosstool-NG messages
    22.8 +# Override the locale early, in case we ever translate crosstool-NG messages
    22.9  if [ -z "${CT_NO_OVERIDE_LC_MESSAGES}" ]; then
   22.10      export LC_ALL=C
   22.11      export LANG=C
   22.12 @@ -79,12 +79,12 @@
   22.13  # Check the user is using an existing SHELL to be used by ./configure and Makefiles
   22.14  CT_TestOrAbort "The CONFIG_SHELL '${CT_CONFIG_SHELL}' (${CT_SHELL}) is not valid" -f "${CT_SHELL}" -a -x "${CT_SHELL}"
   22.15  
   22.16 -# Create the bin-overide early
   22.17 +# Create the bin-override early
   22.18  # Contains symlinks to the tools found by ./configure
   22.19  # Note: CT_DoLog and CT_DoExecLog do not use any of those tool, so
   22.20  # they can be safely used
   22.21  CT_TOOLS_OVERIDE_DIR="${CT_WORK_DIR}/tools"
   22.22 -CT_DoLog DEBUG "Creating bin-overide for tools in '${CT_TOOLS_OVERIDE_DIR}'"
   22.23 +CT_DoLog DEBUG "Creating bin-override for tools in '${CT_TOOLS_OVERIDE_DIR}'"
   22.24  CT_DoExecLog DEBUG mkdir -p "${CT_TOOLS_OVERIDE_DIR}/bin"
   22.25  cat "${CT_LIB_DIR}/paths.mk" |while read trash line; do
   22.26      tool="${line%%=*}"
    23.1 --- a/scripts/patch-rework.sh	Sun Jul 17 16:54:50 2011 +0200
    23.2 +++ b/scripts/patch-rework.sh	Sun Jul 17 16:53:40 2011 +0200
    23.3 @@ -123,7 +123,7 @@
    23.4      read -p "  --> enter patch depth (or Ctrl-C to abort): " d
    23.5    fi
    23.6  
    23.7 -  # Store the original list of fiels touched by the patch,
    23.8 +  # Store the original list of files touched by the patch,
    23.9    # removing the $d leading components
   23.10    sed -r -e "s:^([^/]+/){${d}}::;" "../diffstat.orig" >"${dst}/${pname}.diffstat.orig"
   23.11  
    24.1 --- a/scripts/populate.in	Sun Jul 17 16:54:50 2011 +0200
    24.2 +++ b/scripts/populate.in	Sun Jul 17 16:53:40 2011 +0200
    24.3 @@ -83,7 +83,7 @@
    24.4          If the destination root directory exists, then the content of the
    24.5          source root directory is copied in there, and the result is populated
    24.6          as usual.
    24.7 -        It can be usefull if constructing a rootfs incrementally from many
    24.8 +        It can be useful if constructing a rootfs incrementally from many
    24.9          smaller source root directories, or if your destination root directory
   24.10          is an NFS export that your target mounts as / (and you don't want to
   24.11          re-run exportfs -av everytime). USE WITH CARE!
    25.1 --- a/scripts/showSamples.sh	Sun Jul 17 16:54:50 2011 +0200
    25.2 +++ b/scripts/showSamples.sh	Sun Jul 17 16:53:40 2011 +0200
    25.3 @@ -184,7 +184,7 @@
    25.4  done
    25.5  
    25.6  if [ "${opt}" = -w ]; then
    25.7 -    printf "^ Total: ${#@} samples  || **X**: sample uses features marked as being EXPERIMENTAL.\\\\\\\\ **B**: sample is curently BROKEN. |||||||||||||"
    25.8 +    printf "^ Total: ${#@} samples  || **X**: sample uses features marked as being EXPERIMENTAL.\\\\\\\\ **B**: sample is currently BROKEN. |||||||||||||"
    25.9      echo   ""
   25.10  elif [ -z "${opt}" ]; then
   25.11      echo '      L (Local)       : sample was found in current directory'