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

@@ -1,6 +1,6 @@
 This is a somewhat ordered TODO list:
 
-Recuring tasks:
+Recurring tasks:
 
 - update versions for every tools...
 

config/binutils.in

@@ -12,7 +12,7 @@ config ARCH_BINFMT_ELF
     bool
     prompt "ELF"
     help
-      This will make your system build ELF exectubales,
+      This will make your system build ELF executables,
       suitable for architectures with an MMU.
 
 endif # ARCH_USE_MMU

config/cc.in

@@ -104,7 +104,7 @@ config CC_LANG_OTHERS
       Enter here a comma-separated list of languages that you know your compiler
       supports, besides those listed above.
 
-      Eg. gcc-4.1+ has a toy programming language, treelang. As it is not usefull
+      Eg. gcc-4.1+ has a toy programming language, treelang. As it is not useful
       in real life, it is not available in the selection above.
 
 endif # ! BARE_METAL

config/global/download.in

@@ -23,7 +23,7 @@ config FORCE_DOWNLOAD
     help
       Force downloading tarballs, even if one already exists.
       
-      Usefull if you suspect a tarball to be damaged.
+      Useful if you suspect a tarball to be damaged.
 
 config USE_MIRROR
     bool
@@ -43,7 +43,7 @@ config PREFER_MIRROR
     bool
     prompt "Prefer the mirror"
     help
-      Say 'Y' here if you prefer the LAN miror over the upstream sources.
+      Say 'Y' here if you prefer the LAN mirror over the upstream sources.
 
 config MIRROR_BASE_URL
     string
@@ -93,6 +93,6 @@ config ONLY_DOWNLOAD
     help
       Only download the tarballs. Exit once it done.
       
-      Usefull to pre-retrieve the tarballs before going off-line.
+      Useful to pre-retrieve the tarballs before going off-line.
 
 endif # ! FORBID_DOWNLOAD

config/global/extract.in

@@ -6,9 +6,9 @@ config FORCE_EXTRACT
     bool
     prompt "Force extractions"
     help
-      Force extraction of already exctracted tarballs.
+      Force extraction of already extracted tarballs.
       
-      Usefull if you suspect a previous extract did not complete (eg. broken
+      Useful if you suspect a previous extract did not complete (eg. broken
       tarball), or you added a new set of patches for this component.
 
 config OVERIDE_CONFIG_GUESS_SUB
@@ -37,7 +37,7 @@ config ONLY_EXTRACT
     help
       Exit after unpacking and patching tarballs.
       
-      Usefull to look at the code before doing the build itself.
+      Useful to look at the code before doing the build itself.
 
 choice
     prompt "Patches origin"
@@ -97,7 +97,7 @@ config PATCH_NONE
     help
       Don't use any patch at all.
       
-      Please be carefull if you select this. Most components do require
+      Please be careful if you select this. Most components do require
       patches to properly build. It can happen, however, that support for
       your architecture is clean enough that you can build a toolchain
       with no patch. But most probably, this is *not* the case.
@@ -128,5 +128,5 @@ config LOCAL_PATCH_DIR
     help
       Enter the custom patch directory here.
       
-      Note that you must ensure that the directory contianing your custom
+      Note that you must ensure that the directory containing your custom
       patches is arranged the same way the official directory is.

config/global/paths.in

@@ -69,12 +69,12 @@ config RM_RF_PREFIX_DIR
       If you say 'y' here, then PREFIX_DIR (above) will be eradicated
       prior to the toolchain is built.
       
-      This can be usefull when you are trying different settings (due
+      This can be useful when you are trying different settings (due
       to build failures or feature tests). In this case, to avoid using
       a potentially broken previous toolchain, the install location is
       removed, to start afresh.
       
-      On the oher hand, if you are building a final toolchain, and install
+      On the other hand, if you are building a final toolchain, and install
       it into a directory with pre-install, unrelated programs, it would be
       damageable to remove that directory. In this case, you may want to
       say 'n' here.
@@ -98,7 +98,7 @@ config INSTALL_DIR_RO
       Render the directory of the toolchain (and its sub-directories)
       read-only.
       
-      Usefull for toolchains destined for production.
+      Useful for toolchains destined for production.
 
 config STRIP_ALL_TOOLCHAIN_EXECUTABLES
     bool

config/libc/glibc-eglibc.in-common

@@ -158,7 +158,7 @@ config LIBC_GLIBC_KERNEL_VERSION_NONE
       Let ./configure decide what minimum kernel version glibc/eglibc
       will be able to run against.
       
-      This will inclde legacy compatibility code for older kernels in
+      This will include legacy compatibility code for older kernels in
       the C library, thus ensuring that it will run on a large number
       of old kernels.
       
@@ -173,7 +173,7 @@ config LIBC_GLIBC_KERNEL_VERSION_AS_HEADERS
     bool
     prompt "Same as kernel headers (default)"
     help
-      Normaly, you'll want glibc/eglibc to run against the same kernel
+      Normally, you'll want glibc/eglibc to run against the same kernel
       version as the one used for the headers.
       
       This is the default.

config/target.in

@@ -178,7 +178,7 @@ config ARCH_ABI
       Pick a value from the gcc manual for your choosen gcc version and your
       target CPU.
 
-      Leave blank if you don't know, or if your target architecutre does not
+      Leave blank if you don't know, or if your target architecture does not
       offer this option.
 
 config ARCH_CPU
@@ -282,7 +282,7 @@ config TARGET_CFLAGS
       that will run on the target (eg. libc.so).
       
       Note that the options above for ARCH, ABI, CPU, TUNE and FPU will be
-      automaticaly used. You don't need to specify them here.
+      automatically used. You don't need to specify them here.
       
       Leave blank if you don't know better.
 

config/toolchain.in

@@ -27,7 +27,7 @@ config SYSROOT_NAME
       is 'sysroot' (the default) or 'sys-root'.
       
       You are free to enter anything here, except for spaces, and '/'
-      (see SYSROOT_DIR_PREFIX, below). If you leave this empy, then the
+      (see SYSROOT_DIR_PREFIX, below). If you leave this empty, then the
       default 'sysroot' is used.
 
 config SYSROOT_DIR_PREFIX
@@ -37,7 +37,7 @@ config SYSROOT_DIR_PREFIX
     default ""
     help
       *
-      * Unless you realy know you need that, leave it empty!
+      * Unless you really know you need that, leave it empty!
       *
       
       This string will be interpreted as a directory component to be added
@@ -65,7 +65,7 @@ config STATIC_TOOLCHAIN
       
       If you wish to move the toolchain to another host, and you are not
       confident that this host has the required versions of system libs, then
-      you can say 'Y' here, and all the host tools will be linked staticaly.
+      you can say 'Y' here, and all the host tools will be linked statically.
       
       The impacted tools are:
         - the GNU binutils
@@ -121,7 +121,7 @@ config TARGET_ALIAS_SED_EXPR
     prompt "Tuple's sed transform"
     default ""
     help
-      Normaly, you'd call your toolchain components (especially gcc) by
+      Normally, you'd call your toolchain components (especially gcc) by
       prefixing the target tuple followed by a dash and the component name
       (eg. armeb-unknown-linux-uclibc-gcc).
       
@@ -140,7 +140,7 @@ config TARGET_ALIAS
     prompt "Tuple's alias"
     default ""
     help
-      Normaly, you'd call your toolchain components (especially gcc) by
+      Normally, you'd call your toolchain components (especially gcc) by
       prefixing the target tuple followed by a dash and the component name
       (eg. armeb-unknown-linux-uclibc-gcc).
       

docs/1 - Introduction.txt

@@ -71,7 +71,7 @@ the new versions, due in part to the big effort it was taking.
 So I decided to clean up crosstool in the state it was, re-order the things
 in place, add appropriate support for what I needed, that is uClibc support
 and a menu-driven configuration, named the new implementation crosstool-NG,
-(standing for crosstool Next Generation, as many other comunity projects do,
+(standing for crosstool Next Generation, as many other community projects do,
 and as a wink at the TV series "Star Trek: The Next Generation" ;-) ) and
 made it available to the community, in case it was of interest to any one.
 

docs/2 - Installing crosstool-NG.txt

@@ -13,7 +13,7 @@ There are two ways you can use crosstool-NG:
  - or only build it and run from the source directory.
 
 The former should be used if you got crosstool-NG from a packaged tarball, see
-"Install method", below, while the latter is most useful for developpers that
+"Install method", below, while the latter is most useful for developers that
 use a clone of the repository, and want to submit patches, see "The Hacker's
 way", below.
 
@@ -50,7 +50,7 @@ Stay in the directory holding the sources, and run:
 See below for complete usage.
 
 Now, provided you used a clone of the repository, you can send me your changes.
-See the section titled CONTRIBUTING, below, for how to submit changees.
+See the section titled CONTRIBUTING, below, for how to submit changes.
 
 
 Preparing for packaging |
@@ -82,12 +82,12 @@ To install the shell script fragment, you have two options:
 Contributed code |
 -----------------+
 
-Some people contibuted code that couldn't get merged for various reasons. This
+Some people contributed code that couldn't get merged for various reasons. This
 code is available as lzma-compressed patches, in the contrib/ sub-directory.
 These patches are to be applied to the source of crosstool-NG, prior to
 installing, using something like the following:
   lzcat contrib/foobar.patch.lzma |patch -p1
 
-There is no guarantee that a particuliar contribution applies to the current
+There is no guarantee that a particular contribution applies to the current
 version of crosstool-ng, or that it will work at all. Use contributions at
 your own risk.

docs/3 - Configuring a toolchain.txt

@@ -8,7 +8,7 @@ Configuring crosstool-NG  /
 _________________________/
 
 
-crosstool-NG is configured with a configurator presenting a menu-stuctured set
+crosstool-NG is configured with a configurator presenting a menu-structured set
 of options. These options let you specify the way you want your toolchain
 built, where you want it installed, what architecture and specific processor it
 will support, the version of the components you want to use, etc... The
@@ -50,7 +50,7 @@ Interesting config options |
 ---------------------------+
 
 CT_LOCAL_TARBALLS_DIR:
-  If you already have some tarballs in a direcotry, enter it here. That will
+  If you already have some tarballs in a directory, enter it here. That will
   speed up the retrieving phase, where crosstool-NG would otherwise download
   those tarballs.
 
@@ -67,7 +67,7 @@ CT_TARGET_VENDOR:
   Avoid dots, commas, and special characters.
 
 CT_TARGET_ALIAS:
-  An alias for the toolchian. It will be used as a prefix to the toolchain
+  An alias for the toolchain. It will be used as a prefix to the toolchain
   tools. For example, you will have ${CT_TARGET_ALIAS}-gcc
 
 Also, if you think you don't see enough versions, you can try to enable one of

docs/4 - Building the toolchain.txt

@@ -129,7 +129,7 @@ script is very simple, if not trivial, and works great. The only drawback is
 that it does not work on host systems that lack a shell, for example the
 MingW32 environment. To solve the issue, the wrapper has been re-written in C,
 and compiled at build time. This C wrapper is much more complex than the shell
-script, and although it sems to be working, it's been only lightly tested.
+script, and although it seems to be working, it's been only lightly tested.
 Some of the expected short-comings with this C wrapper are;
  - multi-byte file names may not be handled correctly
  - it's really big for what it does

docs/5 - Using the toolchain.txt

@@ -41,7 +41,7 @@ run:
   your-target-tuple-populate -s /your/root -d /your/root-populated
 
 This will copy /your/root into /your/root-populated, and put the needed and only
-the needed libraries there. Thus you don't polute /your/root with any cruft that
+the needed libraries there. Thus you don't pollute /your/root with any cruft that
 would no longer be needed should you have to remove stuff. /your/root always
 contains only those things you install in it.
 

docs/6 - Toolchain types.txt

@@ -30,7 +30,7 @@ Any toolchain will involve those three machines. You can be as pretty sure of
 this as "2 and 2 are 4". Here is how they come into play:
 
 1) build == host == target
-    This is a plain native toolchain, targetting the exact same machine as the
+    This is a plain native toolchain, targeting the exact same machine as the
     one it is built on, and running again on this exact same machine. You have
     to build such a toolchain when you want to use an updated component, such
     as a newer gcc for example.

docs/8 - Internals.txt

@@ -32,7 +32,7 @@ ct-ng also searches for config files, sub-tools, samples, scripts and patches in
 that library directory.
 
 Because of a stupid make behavior/bug I was unable to track down, implicit make
-rules are disabled: installing with --local would triger those rules, and mconf
+rules are disabled: installing with --local would trigger those rules, and mconf
 was unbuildable.
 
 
@@ -130,7 +130,7 @@ The architecture's ".sh" file API:
      - optional
      - the environment variable CT_TARGET_SYS
      - contains:
-       the sytem part of the target tuple.
+       the system part of the target tuple.
        Eg.: "gnu" for glibc on most architectures
             "gnueabi" for glibc on an ARM EABI
      - defaults to:
@@ -159,7 +159,7 @@ The architecture's ".sh" file API:
        see above.
    + provides:
      - optional
-     - the environement variables to configure the core and final compiler, specific to this architecture:
+     - the environment variables to configure the core and final compiler, specific to this architecture:
        - CT_ARCH_CC_CORE_EXTRA_CONFIG   : additional, architecture specific core gcc ./configure flags
        - CT_ARCH_CC_EXTRA_CONFIG        : additional, architecture specific final gcc ./configure flags
      - default to:

docs/9 - How is a toolchain constructed.txt

@@ -50,13 +50,13 @@ into actual executable code. Depending on the Operating System, or the lack
 thereof, running on the target, we also need the C library. The C library
 provides a standard abstraction layer that performs basic tasks (such as
 allocating memory, printing output on a terminal, managing file access...).
-There are many C libraries, each targetted to different systems. For the
-Linux /desktop/, there is glibc or eglibc or ven uClibc, for embeded Linux,
+There are many C libraries, each targeted to different systems. For the
+Linux /desktop/, there is glibc or eglibc or even uClibc, for embedded Linux,
 you have a choice of eglibc or uClibc, while for system without an Operating
 System, you may use newlib, dietlibc, or even none at all. There a few other
-C libraries, but they are not as widely used, and/or are targetted to very
+C libraries, but they are not as widely used, and/or are targeted to very
 specific needs (eg. klibc is a very small subset of the C library aimed at
-building contrained initial ramdisks).
+building constrained initial ramdisks).
 
 Under Linux, the C library needs to know the API to the kernel to decide
 what features are present, and if needed, what emulation to include for
@@ -168,7 +168,7 @@ is not too recent, chances are that we will have to build those libraries
     correct rounding, MPFR
   - the C library for the arithmetic of complex numbers, MPC
 
-The dependencies for those liraries are:
+The dependencies for those libraries are:
 
   - MPC requires GMP and MPFR
   - MPFR requires GMP
@@ -205,7 +205,7 @@ To enable GRAPHITE:
 To enable LTO:
   - the ELF object file access library, libelf
 
-The depencies for those libraries are:
+The dependencies for those libraries are:
 
   - PPL requires GMP
   - CLooG/PPL requires GMP and PPL
@@ -233,7 +233,7 @@ This list is now complete! Wouhou! :-)
 So the list is complete. But why does crosstool-NG have more steps? |
 --------------------------------------------------------------------+
 
-The already thirteen steps are the necessary steps, from a theorical point
+The already thirteen steps are the necessary steps, from a theoretical point
 of view. In reality, though, there are small differences; there are three
 different reasons for the additional steps in crosstool-NG.
 
@@ -249,9 +249,9 @@ libc_finish step.
 
 Third, crosstool-NG can also build some additional debug utilities to run on
 the target. This is where we build, for example, the cross-gdb, the gdbserver
-and the native gdb (the last two run on the target, the furst runs on the
+and the native gdb (the last two run on the target, the first runs on the
 same machine as the toolchain). The others (strace, ltrace, DUMA and dmalloc)
 are absolutely not related to the toolchain, but are nice-to-have stuff that
-can greatly help when developping, so are included as goodies (and they are
+can greatly help when developing, so are included as goodies (and they are
 quite easy to build, so it's OK; more complex stuff is not worth the effort
 to include in crosstool-NG).

docs/B - Known issues.txt

@@ -7,7 +7,7 @@ Known issues  /
 _____________/
 
 
-This files lists the known issues encountered while developping crosstool-NG,
+This files lists the known issues encountered while developing crosstool-NG,
 but that could not be addressed before the release.
 
 The file has one section for each known issue, each section containing four
@@ -136,7 +136,7 @@ Symptoms:
 Explanations:
   The gcc build procedure tries to run a Fortran test to see if it has a
   working native fortran compiler installed on the build machine, and it
-  can't find one. A native Fortran compiler is needed (seems to be neede)
+  can't find one. A native Fortran compiler is needed (seems to be needed)
   to build the Fortran frontend of the cross-compiler.
   Even if you don't want to build the Fortran frontend, gcc tries to see
   if it has one, but fails. This is no problem, as the Fortran frontend

docs/C - Misc. tutorials.txt

@@ -275,7 +275,7 @@ In this case, before executing the hg qpush -a from above
 you should manually "hg qdelete" the patches that are already integrated upstream.
 
 
-HOW TO FORMAT COMMIT MESSAGES (aka patch desciptions):
+HOW TO FORMAT COMMIT MESSAGES (aka patch descriptions):
 
 Commit messages should look like (without leading pipes):
  |component: short, one-line description

docs/ct-ng.1.in

@@ -99,7 +99,7 @@ to canonicalise the machines' name (host, build and target machines).
 Builds a tarball of the generated toolchain, also saving the scripts from
 .B crosstool-NG
 that are needed to rebuild the target, and also saving the tarballs of the
-componnents that were used.
+components that were used.
 ."
 .SH ENVIRONMENT
 .TP
@@ -107,7 +107,7 @@ componnents that were used.
 Respectively stops and restarts the build just before this step. To restart a
 step, a previous build should have run at least to that step, or further.
 
-The list of steps is vailable with the action
+The list of steps is viewable with the action
 .BR list-steps .
 ."
 .SH EXIT VALUE

kconfig/kconfig.mk

@@ -129,7 +129,7 @@ ALL_DEPS = $(sort $(COMMON_DEP) $(LX_DEP) $(conf_DEP) $(mconf_DEP) $(nconf_DEP))
 # Cheesy auto-dependencies
 # Only parse the following if a configurator was called, to avoid building
 # dependencies when not needed (eg. list-steps, list-samples...)
-# We must be carefull what we enclose, because we need some of the variable
+# We must be careful what we enclose, because we need some of the variable
 # definitions for clean (and distclean) at least.
 # Just protecting the "-include $(DEPS)" line should be sufficient.
 # And in case we want menuconfig, we have to check that lxdialog
@@ -159,7 +159,7 @@ endif # MAKECMDGOALS != ""
 
 # Each .o or .dep *can not* directly depend on kconfig/, because kconfig can
 # be touched during the build (who's touching it, btw?) so each .o or .dep
-# would be re-built when it sould not be.
+# would be re-built when it should not be.
 # So manually check for presence of $(obj) (ie. kconfig), and only mkdir
 # if needed. After all, that's not so bad...
 # mkdir $(obj)/lxdialog, because we need it, and incidentally, that

scripts/crosstool-NG.sh.in

@@ -25,7 +25,7 @@
 . .config.2
 # Yes! We can do full logging from now on!
 
-# Overide the locale early, in case we ever translate crosstool-NG messages
+# Override the locale early, in case we ever translate crosstool-NG messages
 if [ -z "${CT_NO_OVERIDE_LC_MESSAGES}" ]; then
     export LC_ALL=C
     export LANG=C
@@ -79,12 +79,12 @@ esac
 # Check the user is using an existing SHELL to be used by ./configure and Makefiles
 CT_TestOrAbort "The CONFIG_SHELL '${CT_CONFIG_SHELL}' (${CT_SHELL}) is not valid" -f "${CT_SHELL}" -a -x "${CT_SHELL}"
 
-# Create the bin-overide early
+# Create the bin-override early
 # Contains symlinks to the tools found by ./configure
 # Note: CT_DoLog and CT_DoExecLog do not use any of those tool, so
 # they can be safely used
 CT_TOOLS_OVERIDE_DIR="${CT_WORK_DIR}/tools"
-CT_DoLog DEBUG "Creating bin-overide for tools in '${CT_TOOLS_OVERIDE_DIR}'"
+CT_DoLog DEBUG "Creating bin-override for tools in '${CT_TOOLS_OVERIDE_DIR}'"
 CT_DoExecLog DEBUG mkdir -p "${CT_TOOLS_OVERIDE_DIR}/bin"
 cat "${CT_LIB_DIR}/paths.mk" |while read trash line; do
     tool="${line%%=*}"

scripts/patch-rework.sh

@@ -123,7 +123,7 @@ $1=="+++" && mark==1 { nextfile; }
     read -p "  --> enter patch depth (or Ctrl-C to abort): " d
   fi
 
-  # Store the original list of fiels touched by the patch,
+  # Store the original list of files touched by the patch,
   # removing the $d leading components
   sed -r -e "s:^([^/]+/){${d}}::;" "../diffstat.orig" >"${dst}/${pname}.diffstat.orig"
 

scripts/populate.in

@@ -83,7 +83,7 @@ OPTIONS
         If the destination root directory exists, then the content of the
         source root directory is copied in there, and the result is populated
         as usual.
-        It can be usefull if constructing a rootfs incrementally from many
+        It can be useful if constructing a rootfs incrementally from many
         smaller source root directories, or if your destination root directory
         is an NFS export that your target mounts as / (and you don't want to
         re-run exportfs -av everytime). USE WITH CARE!

scripts/showSamples.sh

@@ -184,7 +184,7 @@ for sample in "${@}"; do
 done
 
 if [ "${opt}" = -w ]; then
-    printf "^ Total: ${#@} samples  || **X**: sample uses features marked as being EXPERIMENTAL.\\\\\\\\ **B**: sample is curently BROKEN. |||||||||||||"
+    printf "^ Total: ${#@} samples  || **X**: sample uses features marked as being EXPERIMENTAL.\\\\\\\\ **B**: sample is currently BROKEN. |||||||||||||"
     echo   ""
 elif [ -z "${opt}" ]; then
     echo '      L (Local)       : sample was found in current directory'