FYI: ltmain.in spelling nits.

[Robert Boehne]

FYI,

Here is a patch that fixes a few typos, but mostly changes
UK English into US English.  Sorry, Gary.  ;)
I decided to do this because a few patches had been
submitted, but none were complete as this one.

Thanks to those who pointed them out.

ChangeLog entry:

2002-09-24  Robert Boehne  <address@hidden>

        * ltmain.in: Fixed a few spelling errors.

Index: ltmain.in
===================================================================
RCS file: /cvsroot/libtool/libtool/ltmain.in,v
retrieving revision 1.300
diff -u -r1.300 ltmain.in
--- ltmain.in   9 Sep 2002 18:26:34 -0000       1.300
+++ ltmain.in   25 Sep 2002 04:08:26 -0000
@@ -478,7 +478,7 @@
     if test -n "$available_tags" && test -z "$tagname"; then
       case $base_compile in
       # Blanks in the command may have been stripped by the calling shell,
-      # but not from the CC environment variable when ltconfig was run.
+      # but not from the CC environment variable when configure was run.
       " $CC "* | "$CC "* | " `$echo $CC` "* | "`$echo $CC` "*) ;;
       # Blanks at the start of $base_compile will cause this to fail
       # if we don't check for them as well.
@@ -776,7 +776,7 @@
       # It is impossible to link a dll without this setting, and
       # we shouldn't force the makefile maintainer to figure out
       # which system we are compiling for in order to pass an extra
-      # flag for every libtool invokation.
+      # flag for every libtool invocation.
       # allow_undefined=no
 
       # FIXME: Unfortunately, there are problems with the above when trying
@@ -1524,7 +1524,7 @@
     if test -n "$available_tags" && test -z "$tagname"; then
       case $base_compile in
       # Blanks in the command may have been stripped by the calling shell,
-      # but not from the CC environment variable when ltconfig was run.
+      # but not from the CC environment variable when configure was run.
       "$CC "* | " $CC "* | "`$echo $CC` "* | " `$echo $CC` "*) ;;
       # Blanks at the start of $base_compile will cause this to fail
       # if we don't check for them as well.
@@ -1614,7 +1614,7 @@
       # the link line twice: once before the "normal" libs
       # (-lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32) and
       # once AFTER those.  However, the "eliminate dup deps"
-      # proceedure keeps only the LAST duplicate -- thus
+      # procedure keeps only the LAST duplicate -- thus
       # messing up the order, since after dup elimination
       # -lgcc comes AFTER -lcygwin.  In normal C operation,
       # you don't notice the problem, because -lgcc isn't
@@ -2877,7 +2877,7 @@
          # This might be a little naive.  We might want to check
          # whether the library exists or not.  But this is on
          # osf3 & osf4 and I'm not really sure... Just
-         # implementing what was already the behaviour.
+         # implementing what was already the behavior.
          newdeplibs=$deplibs
          ;;
        test_compile)
@@ -2918,7 +2918,7 @@
              fi
            done
          else
-           # Error occured in the first compile.  Let's try to salvage
+           # Error occurred in the first compile.  Let's try to salvage
            # the situation: Compile a separate program for each library.
            for i in $deplibs; do
              name="`expr $i : '-l\(.*\)'`"
@@ -5184,7 +5184,7 @@
        eval "export $shlibpath_var"
       fi
 
-      # Restore saved enviroment variables
+      # Restore saved environment variables
       if test "${save_LC_ALL+set}" = set; then
        LC_ALL="$save_LC_ALL"; export LC_ALL
       fi