From c009897aeec4ac3265498664937b2b86870b9984 Mon Sep 17 00:00:00 2001 From: "Yann E. MORIN\"" Date: Sun, 17 Jul 2011 16:53:40 +0200 Subject: misc: fix more typos here and there... Reported-by: "Antony N. Pavlov" Signed-off-by: "Yann E. MORIN" diff --git a/TODO b/TODO index ab17fe8..0ade3ef 100644 --- a/TODO +++ b/TODO @@ -1,6 +1,6 @@ This is a somewhat ordered TODO list: -Recuring tasks: +Recurring tasks: - update versions for every tools... diff --git a/config/binutils.in b/config/binutils.in index 4779708..dc269bb 100644 --- a/config/binutils.in +++ b/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 diff --git a/config/cc.in b/config/cc.in index 4c4c3c1..680afb9 100644 --- a/config/cc.in +++ b/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 diff --git a/config/global/download.in b/config/global/download.in index d128866..b678374 100644 --- a/config/global/download.in +++ b/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 diff --git a/config/global/extract.in b/config/global/extract.in index 3f45ec0..2599faa 100644 --- a/config/global/extract.in +++ b/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. diff --git a/config/global/paths.in b/config/global/paths.in index 2a1fa67..f7766da 100644 --- a/config/global/paths.in +++ b/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 diff --git a/config/libc/glibc-eglibc.in-common b/config/libc/glibc-eglibc.in-common index a3ee9c1..255edb7 100644 --- a/config/libc/glibc-eglibc.in-common +++ b/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. diff --git a/config/target.in b/config/target.in index 59c3001..8282a9d 100644 --- a/config/target.in +++ b/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. diff --git a/config/toolchain.in b/config/toolchain.in index 25605cb..5e45fc7 100644 --- a/config/toolchain.in +++ b/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). diff --git a/docs/1 - Introduction.txt b/docs/1 - Introduction.txt index 3728cbf..15870ab 100644 --- a/docs/1 - Introduction.txt +++ b/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. diff --git a/docs/2 - Installing crosstool-NG.txt b/docs/2 - Installing crosstool-NG.txt index 1f85c7b..69909fe 100644 --- a/docs/2 - Installing crosstool-NG.txt +++ b/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. diff --git a/docs/3 - Configuring a toolchain.txt b/docs/3 - Configuring a toolchain.txt index 092ac0a..1eb6149 100644 --- a/docs/3 - Configuring a toolchain.txt +++ b/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 diff --git a/docs/4 - Building the toolchain.txt b/docs/4 - Building the toolchain.txt index 62f0a95..6e24bc0 100644 --- a/docs/4 - Building the toolchain.txt +++ b/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 diff --git a/docs/5 - Using the toolchain.txt b/docs/5 - Using the toolchain.txt index 4d61514..eb8e1aa 100644 --- a/docs/5 - Using the toolchain.txt +++ b/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. diff --git a/docs/6 - Toolchain types.txt b/docs/6 - Toolchain types.txt index 3e3b3df..382ceb6 100644 --- a/docs/6 - Toolchain types.txt +++ b/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. diff --git a/docs/8 - Internals.txt b/docs/8 - Internals.txt index 087b18c..816acc6 100644 --- a/docs/8 - Internals.txt +++ b/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: diff --git a/docs/9 - How is a toolchain constructed.txt b/docs/9 - How is a toolchain constructed.txt index 3290f0d..cc8e6a6 100644 --- a/docs/9 - How is a toolchain constructed.txt +++ b/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). diff --git a/docs/B - Known issues.txt b/docs/B - Known issues.txt index 4979818..c7ae903 100644 --- a/docs/B - Known issues.txt +++ b/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 diff --git a/docs/C - Misc. tutorials.txt b/docs/C - Misc. tutorials.txt index 6fc03da..18d9d2c 100644 --- a/docs/C - Misc. tutorials.txt +++ b/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 diff --git a/docs/ct-ng.1.in b/docs/ct-ng.1.in index 6576d34..d711369 100644 --- a/docs/ct-ng.1.in +++ b/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 diff --git a/kconfig/kconfig.mk b/kconfig/kconfig.mk index a191eaf..7a6af5e 100644 --- a/kconfig/kconfig.mk +++ b/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 diff --git a/scripts/crosstool-NG.sh.in b/scripts/crosstool-NG.sh.in index be51e07..509a74b 100644 --- a/scripts/crosstool-NG.sh.in +++ b/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%%=*}" diff --git a/scripts/patch-rework.sh b/scripts/patch-rework.sh index 9b9f912..3d97795 100755 --- a/scripts/patch-rework.sh +++ b/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" diff --git a/scripts/populate.in b/scripts/populate.in index 02b1797..5d8f595 100644 --- a/scripts/populate.in +++ b/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! diff --git a/scripts/showSamples.sh b/scripts/showSamples.sh index d96d0c5..e510b3d 100755 --- a/scripts/showSamples.sh +++ b/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' -- cgit v0.10.2-6-g49f6