[0/2] sh.test adjustments

[Peter Rosin]

Hi!

Since I tripped up and made sh.test fail, to repent I'd thought I'd
move the test to the new testsuite. But then I noticed a bug, so it
turned into a two patch series...

Ok to push?

Cheers,
Peter

[PATCH 1/2] * tests/sh.test: Detect missing 'test' in 'if "$foo" = ...'.

[Peter Rosin]

>From 75358282c6674d399e76c42eb456ed20b73c358a Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Fri, 17 Sep 2010 12:15:00 +0200
Subject: [PATCH 1/2] * tests/sh.test: Detect missing 'test' in 'if "$foo" = 
...'.

Signed-off-by: Peter Rosin 
---
 ChangeLog |4 
 tests/sh.test |6 +++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 37f6c84..a6f7d42 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2010-09-17  Peter Rosin  
+
+   * tests/sh.test: Detect missing 'test' in 'if "$foo" = ...'.
+
 2010-09-16  Ralf Wildenhues  
 
tests: avoid localization failure due to unstable compiler messages.
diff --git a/tests/sh.test b/tests/sh.test
index 6d2fa20..5324b31 100755
--- a/tests/sh.test
+++ b/tests/sh.test
@@ -2,8 +2,8 @@
 # sh.test - check for some nonportable or dubious or undesired shell
 #   constructs in shell scripts.
 #
-#   Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008 Free Software
-#   Foundation, Inc.
+#   Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2010 Free
+#   Software Foundation, Inc.
 #   Written by Gary V. Vaughan, 2003
 #
 #   This file is part of GNU Libtool.
@@ -31,7 +31,7 @@
 status=$EXIT_SUCCESS
 
 # Check for bad binary operators.
-if $EGREP -n -e 'if[   ]+["'\'']?\\$[^ ]+[ 
]+(=|-[lg][te]|-eq|-ne)' $scripts; then
+if $EGREP -n -e 'if[   ]+["'\'']?\$[^  ]+[ ]+(=|-[lg][te]|-eq|-ne)' 
$scripts; then
   echo "use \`if test \$something =' instead of \`if \$something ='"
   status=$EXIT_FAILURE
 fi
-- 
1.7.1

[PATCH 2/2] Move portable shell tests from the old to the new testsuite.

[Peter Rosin]

>From c6195aeb806270200950a86cda955ca674e680f1 Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Fri, 17 Sep 2010 12:28:51 +0200
Subject: [PATCH 2/2] Move portable shell tests from the old to the new 
testsuite.

* tests/sh.test: Move this...
* tests/sh.at: ...to here, and adjust to the new testsuite.
* Makefile.am: Update.
---
 ChangeLog |5 ++
 Makefile.am   |2 +-
 tests/sh.at   |  143 +
 tests/sh.test |  134 -
 4 files changed, 149 insertions(+), 135 deletions(-)
 create mode 100644 tests/sh.at
 delete mode 100755 tests/sh.test

diff --git a/ChangeLog b/ChangeLog
index a6f7d42..ba1c1fe 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
 2010-09-17  Peter Rosin  
 
+   Move portable shell tests from the old to the new testsuite.
+   * tests/sh.test: Move this...
+   * tests/sh.at: ...to here, and adjust to the new testsuite.
+   * Makefile.am: Update.
+
* tests/sh.test: Detect missing 'test' in 'if "$foo" = ...'.
 
 2010-09-16  Ralf Wildenhues  
diff --git a/Makefile.am b/Makefile.am
index dcd0876..db9ff78 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -440,6 +440,7 @@ dist-hook:
 # The testsuite files are evaluated in the order given here.
 TESTSUITE  = tests/testsuite
 TESTSUITE_AT   = tests/testsuite.at \
+ tests/sh.at \
  tests/getopt-m4sh.at \
  tests/libtoolize.at \
  tests/help.at \
@@ -687,7 +688,6 @@ COMMON_TESTS = \
tests/nomode.test \
tests/objectlist.test \
tests/quote.test \
-   tests/sh.test \
tests/suffix.test \
tests/tagtrace.test \
tests/cdemo-static.test \
diff --git a/tests/sh.at b/tests/sh.at
new file mode 100644
index 000..7c5633c
--- /dev/null
+++ b/tests/sh.at
@@ -0,0 +1,143 @@
+# sh.at - check for some nonportable or dubious or undesired shell
+# constructs in shell scripts.
+#
+#   Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2010 Free
+#   Software Foundation, Inc.
+#   Written by Gary V. Vaughan, 2003
+#
+#   This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Libtool; see the file COPYING.  If not, a copy
+# can be downloaded from  http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+
+AT_BANNER([Maintainer checks.])
+
+AT_SETUP([portable m4sh scripts])
+
+m4dir=$top_srcdir/libltdl/m4
+auxdir=$top_srcdir/libltdl/config
+scripts="$auxdir/ltmain.m4sh $top_srcdir/libtoolize.m4sh"
+
+# Check all the "portable" shell scripts.
+status=:
+
+[
+# Check for bad binary operators.
+if $EGREP -n -e 'if[   ]+["'\'']?\$[^  ]+[ ]+(=|-[lg][te]|-eq|-ne)' 
$scripts; then
+  echo "use \`if test \$something =' instead of \`if \$something ='"
+  status=false
+fi
+
+# Check for bad unary operators.
+if $EGREP -n -e 'if[   ]+-' $scripts; then
+  echo "use \`if test -X' instead of \`if -X'"
+  status=false
+fi
+
+# Check for using `@<:@' instead of `test'. @<:@ is a square bracket.
+if $EGREP -n -e 'if[   ]+\@<:@' $scripts; then
+  echo "use \`if test' instead of \`if @<:@'"
+  status=false
+fi
+
+# Check for using test X... instead of test "X...
+if $EGREP -n -e 'test[ ]+(![   ])?(-.[ ]+)?X' $scripts; then
+  echo "use \`test \"X...\"' instead of \`test X'"
+  status=false
+fi
+
+# Check for using test $... instead of test "$...
+if $EGREP -n -e 'test[ ]+(![   ])?(-.[ ]+)?X?\$' $scripts; then
+  echo "use \`test \"\$...\"' instead of \`test \$'"
+  status=false
+fi
+
+# Never use test -e.
+if $EGREP -n -e 'test[ ]+(![   ])?-e' $scripts; then
+  echo "use \`test -f' instead of \`test -e'"
+  status=false
+fi
+
+# Check for uses of Xsed without corresponding echo "X
+if $EGREP -n -e '\$Xsed' $scripts | $EGREP -v -n -e '\$ECHO \\*"X'; then
+  echo "occurrences of \`\$Xsed\' without \`echo \"X\' on the same line"
+  status=false
+fi
+
+# Check for quotes within backquotes within quotes "`"bar"`"
+if $EGREP -n -e '"[^`"]*`[^"`]*"[^"`]*".*`[^`"]*"' $scripts | \
+   $EGREP -v "### testsuite: skip nested quoting test$"; then
+  echo "nested quotes are dangerous"
+  status=false
+fi
+
+# Check for using set -- instead of set dummy
+if $EGREP -n -e 'set[  ]+--[   ]+' $scripts; then
+  echo "use \`set dummy

[PATCH] Copy over DLL_EXPORT handling from C to C++ for non-GCC on w32.

[Peter Rosin]

Hi!

I noticed that -DDLL_EXPORT didn't appear when I compiled C++ code
with MSVC.

I'd like this one to go in before the release.

Ok to push?

Cheers,
Peter


>From 0114c5a834fb1ce8e8324ff6d7c0bb782139c3c7 Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Fri, 17 Sep 2010 16:15:04 +0200
Subject: [PATCH] Copy over DLL_EXPORT handling from C to C++ for non-GCC on w32.

* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [mingw, cygwin, os2]
[pw32, cegcc]: Copy over the DLL_EXPORT handling from C to C++.

Signed-off-by: Peter Rosin 
---
 ChangeLog |6 ++
 libltdl/m4/libtool.m4 |6 ++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 44a76e2..dbbc21f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-09-17  Peter Rosin  
+
+   Copy over DLL_EXPORT handling from C to C++ for non-GCC on w32.
+   * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [mingw, cygwin, os2]
+   [pw32, cegcc]: Copy over the DLL_EXPORT handling from C to C++.
+
 2010-09-16  Charles Wilson  
 
Fix sh.test failure introduced in 72064249
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 3a4e757..ec7804e 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3873,6 +3873,12 @@ m4_if([$1], [CXX], [
  ;;
esac
;;
+  mingw* | cygwin* | os2* | pw32* | cegcc*)
+   # This hack is so that the source file can tell whether it is being
+   # built for inclusion in a dll (and should export symbols for example).
+   m4_if([$1], [GCJ], [],
+ [_LT_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'])
+   ;;
   dgux*)
case $cc_basename in
  ec++*)
-- 
1.7.1

[PATCH] Fix order of PATH manipulation in cwrapper and shwrapper

[Charles Wilson]

* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src:main): Call
lt_update_exe_path before lt_update_lib_path, to ensure that the
temporary rpath values (which include the OBJDIRs of uninstalled
libtool libraries) precede installation and final -rpath directories.
(func_emit_wrapper): Prepend $dllsearchpath to PATH before prepending
$temp_rpath to $shlibpath_var; similar rationale as above.
Reported by Jon Turney 
---
As promised here:
http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00191.html

Tested on cygwin; no regressions:
old: All 122 tests passed (2 tests were not run)
new: 111 tests behaved as expected. 9 tests were skipped.

OK to push?

 libltdl/config/ltmain.m4sh |   31 ++-
 1 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 7bbca85..2371a14 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -3293,6 +3293,22 @@ func_exec_program ()
 
   if test -f \"\$progdir/\$program\"; then"
 
+   # fixup the dll searchpath if we need to.
+   #
+   # For Windows, this must occur prior to any manipulation of
+   # $shlibpath (which, ON Windows, is PATH).  That way, we ensure
+   # that the $dllsearchpath value is prepended to $PATH first, and
+   # that the temporary rpath values (which contain the actual
+   # location of uninstalled DLLs, in their respective OBJDIR
+   # directories) are prepended second.  This ensures that just-built
+   # uninstalled libraries supersede installed ones.
+   if test -n "$dllsearchpath"; then
+ $ECHO "\
+# Add the dll search path components to the executable PATH
+PATH=$dllsearchpath:\$PATH
+"
+   fi
+
# Export our shlibpath_var if we have one.
if test "$shlibpath_overrides_runpath" = yes && test -n 
"$shlibpath_var" && test -n "$temp_rpath"; then
  $ECHO "\
@@ -3307,14 +3323,6 @@ func_exec_program ()
 "
fi
 
-   # fixup the dll searchpath if we need to.
-   if test -n "$dllsearchpath"; then
- $ECHO "\
-# Add the dll search path components to the executable PATH
-PATH=$dllsearchpath:\$PATH
-"
-   fi
-
$ECHO "\
 if test \"\$libtool_execute_magic\" != \"$magic\"; then
   # Run the actual program with our arguments.
@@ -3703,8 +3711,13 @@ EOF
 
   lt_setenv ("BIN_SH", "xpg4"); /* for Tru64 */
   lt_setenv ("DUALCASE", "1");  /* for MSK sh */
-  lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE);
+  /* For Windows, this order is important: it ensures that the $dllsearchpath
+ value is prepended first, and that the temporary rpath values (which
+ contain the actual location of uninstalled DLLs, in their respective
+ OBJDIR directories) are prepended second.  This ensures that just-built
+ uninstalled libraries supersede installed ones. */
   lt_update_exe_path (EXE_PATH_VARNAME, EXE_PATH_VALUE);
+  lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE);
 
   lt_debugprintf (__FILE__, __LINE__, "(main) lt_argv_zero: %s\n",
  nonnull (lt_argv_zero));
-- 
1.7.1

[PATCH] Document libtool variable to_host_file_cmd.

[Charles Wilson]

* doc/libtool.texi (libtool script contents:to_host_file_cmd): Document
variable.
(libtool script contents:to_tool_file_cmd): Prefer `build platform'
to `build system'; Ditto `host platform'.
---
As promised here:
http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00191.html

OK to push?


 doc/libtool.texi |   14 --
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/doc/libtool.texi b/doc/libtool.texi
index a3555dc..0d3ff7f 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -6822,11 +6822,21 @@ Linker flag (passed through the C compiler) used to 
generate thread-safe
 libraries.
 @end defvar
 
+...@defvar to_host_file_cmd
+If the toolchain is not native to the build platform (e.g.@: if you are using
+MSYS to drive the scripting, but are using the MinGW native Windows compiler)
+this variable describes how to convert file names from the format used by the
+build platform to the format used by host platform.  Normally set to
+...@samp{func_convert_file_noop}, libtool will autodetect most cases in which
+other values should be used.  On rare occasions, it may be necessary to 
override
+the autodetected value (@pxref{Cygwin to MinGW Cross}).
+...@end defvar
+
 @defvar to_tool_file_cmd
-If the toolchain is not native to the build system (e.g.@: if you are using
+If the toolchain is not native to the build platform (e.g.@: if you are using
 some Unix to drive the scripting together with a Windows toolchain running
 in Wine) this variable describes how to convert file names from the format
-used by the build system to the format used by the toolchain.  Normally set
+used by the build platform to the format used by the toolchain.  Normally set
 to @samp{func_convert_file_noop}.
 @end defvar
 
-- 
1.7.1

Re: [PATCH] Copy over DLL_EXPORT handling from C to C++ for non-GCC on w32.

[Ralf Wildenhues]

let the review sprint begin ...

Hi Peter,

* Peter Rosin wrote on Fri, Sep 17, 2010 at 04:18:55PM CEST:
> I noticed that -DDLL_EXPORT didn't appear when I compiled C++ code
> with MSVC.
> 
> I'd like this one to go in before the release.
> 
> Ok to push?

OK, thanks.

Testsuite exposure would be nice at some point.

In this macro, there are 4 cases, with the first criterion being decided
at autoconf time, the second at configure time:
1)  $1 = CXX$CXX = yes
2)  $1 = CXX$CXX != yes
3)  $1 != CXX   $GCC = yes
4)  $1 != CXX   $GCC != yes

your code fixes case (2).  After the change, the mingw bits of
the cases (1) and (2) both superfluously compare $1 to GCJ; that is
not needed, because $1 is CXX.  You may simplify both cases accordingly.

Thanks,
Ralf

> Subject: [PATCH] Copy over DLL_EXPORT handling from C to C++ for non-GCC on 
> w32.
> 
> * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [mingw, cygwin, os2]
> [pw32, cegcc]: Copy over the DLL_EXPORT handling from C to C++.

> --- a/libltdl/m4/libtool.m4
> +++ b/libltdl/m4/libtool.m4
> @@ -3873,6 +3873,12 @@ m4_if([$1], [CXX], [

see here:^

> ;;
>   esac
>   ;;
> +  mingw* | cygwin* | os2* | pw32* | cegcc*)
> + # This hack is so that the source file can tell whether it is being
> + # built for inclusion in a dll (and should export symbols for example).
> + m4_if([$1], [GCJ], [],
> +   [_LT_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'])
> + ;;
>dgux*)
>   case $cc_basename in
> ec++*)

Re: [PATCH 1/2] * tests/sh.test: Detect missing 'test' in 'if "$foo" = ...'.

[Ralf Wildenhues]

* Peter Rosin wrote on Fri, Sep 17, 2010 at 12:37:07PM CEST:
> Subject: [PATCH 1/2] * tests/sh.test: Detect missing 'test' in 'if "$foo" = 
> ...'.

OK, but I find the log entry not really explaining the change.
How about this instead?

tests: actually detect missing 'test' in 'if "$foo" = ...'.

* tests/sh.test: Remove extra backslash in regex.

Thanks,
Ralf

> @@ -31,7 +31,7 @@
>  status=$EXIT_SUCCESS
>  
>  # Check for bad binary operators.
> -if $EGREP -n -e 'if[ ]+["'\'']?\\$[^ ]+[ 
> ]+(=|-[lg][te]|-eq|-ne)' $scripts; then
> +if $EGREP -n -e 'if[ ]+["'\'']?\$[^  ]+[ 
> ]+(=|-[lg][te]|-eq|-ne)' $scripts; then
>echo "use \`if test \$something =' instead of \`if \$something ='"
>status=$EXIT_FAILURE
>  fi

Re: [PATCH] Copy over DLL_EXPORT handling from C to C++ for non-GCC on w32.

[Charles Wilson]

On 9/17/2010 12:53 PM, Ralf Wildenhues wrote:
> let the review sprint begin ...

Meh -- no more patches from me in the near term.  I promised two small
patches yesterday, delivered today.  Whether they are reviewed and
pushed before the release or not doesn't matter that much.

--
Chuck

Re: [PATCH 2/2] Move portable shell tests from the old to the new testsuite.

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Fri, Sep 17, 2010 at 12:37:30PM CEST:
> Subject: [PATCH 2/2] Move portable shell tests from the old to the new 
> testsuite.
> 
> * tests/sh.test: Move this...
> * tests/sh.at: ...to here, and adjust to the new testsuite.
> * Makefile.am: Update.

> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -440,6 +440,7 @@ dist-hook:
>  # The testsuite files are evaluated in the order given here.
>  TESTSUITE= tests/testsuite
>  TESTSUITE_AT = tests/testsuite.at \
> +   tests/sh.at \
> tests/getopt-m4sh.at \
> tests/libtoolize.at \
> tests/help.at \

At some point we should probably clean up ordering of tests and banners
a bit ...

> diff --git a/tests/sh.at b/tests/sh.at
> new file mode 100644
> index 000..7c5633c
> --- /dev/null
> +++ b/tests/sh.at
> @@ -0,0 +1,143 @@
> +# sh.at - check for some nonportable or dubious or undesired shell
> +# constructs in shell scripts.

Not sure if emacs wants '-*- Autotest -*-' in that first line somewhere
for syntax highlighting?

> +#
> +#   Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2010 Free
> +#   Software Foundation, Inc.
> +#   Written by Gary V. Vaughan, 2003

I really don't know how to handle author annotations well when moving
things.  "Code taken from sh.test, written by ..."?

(As an aside issue, I've pondered removing author tags from tests which
*I* alone wrote; but I understand the topic is sensitive and subjective
and I respect differing opinions on this, so I'm not suggesting it for
anybody else ... see recent discussions on automake-patches and
bug-gnulib.)

> +AT_BANNER([Maintainer checks.])
> +
> +AT_SETUP([portable m4sh scripts])
> +
> +m4dir=$top_srcdir/libltdl/m4
> +auxdir=$top_srcdir/libltdl/config
> +scripts="$auxdir/ltmain.m4sh $top_srcdir/libtoolize.m4sh"
> +
> +# Check all the "portable" shell scripts.
> +status=:

status is a special variable for zsh, so should not be used.  But see
below.

> +[
> +# Check for bad binary operators.
> +if $EGREP -n -e 'if[ ]+["'\'']?\$[^  ]+[ 
> ]+(=|-[lg][te]|-eq|-ne)' $scripts; then
> +  echo "use \`if test \$something =' instead of \`if \$something ='"
> +  status=false
> +fi

Please don't do this.  The Autotest way is to use AT_CHECK for anything
that can meaningfully go wrong, and whose output may be interesting to
have logged (or checked, or both).  Otherwise TESTSUITEFLAGS=-v will not
produce helpful output.

Hmm, according to autoconf.texi, egrep shares grep's limitations, and
grep -e is not portable; I wonder if that is not actually a problem,
as Solaris 2.6 /usr/bin/egrep groks -e, unlike its /usr/bin/grep.

While rewriting these tests, it would be nice to have TABs before
spaces, less likely to get garbage-collected by editors.

So, I'd write the above as something like this (mind the m4 double
quoting so the regexes come out right):

  # Check for bad binary operators.
  AT_CHECK([[$EGREP -n 'if[ ]+["'\'']?\$[^  ]+[ 
]+(=|-[lg][te]|-eq|-ne)' ]]dnl
   [$scripts], [1], [], [],
   [echo "use \`if test \$something =' instead of \`if \$something ='"])

Likewise for all the other tests.

The patch is OK with those issues fixed, but since the chance of typos
is fairly high it'd be nice if you could retest and give us 24 hours to
check your updated patch for issues on some systems.  And since IIRC
Gary wanted to do the release this weekend, I wonder whether this isn't
more safely pushed to after the relase.  WDYT?

Thanks,
Ralf

> +# Check for bad unary operators.
> +if $EGREP -n -e 'if[ ]+-' $scripts; then
> +  echo "use \`if test -X' instead of \`if -X'"
> +  status=false
> +fi
> +
> +# Check for using `@<:@' instead of `test'. @<:@ is a square bracket.
> +if $EGREP -n -e 'if[ ]+\@<:@' $scripts; then
> +  echo "use \`if test' instead of \`if @<:@'"
> +  status=false
> +fi
> +
> +# Check for using test X... instead of test "X...
> +if $EGREP -n -e 'test[   ]+(![   ])?(-.[ ]+)?X' $scripts; then
> +  echo "use \`test \"X...\"' instead of \`test X'"
> +  status=false
> +fi
> +
> +# Check for using test $... instead of test "$...
> +if $EGREP -n -e 'test[   ]+(![   ])?(-.[ ]+)?X?\$' $scripts; then
> +  echo "use \`test \"\$...\"' instead of \`test \$'"
> +  status=false
> +fi
> +
> +# Never use test -e.
> +if $EGREP -n -e 'test[   ]+(![   ])?-e' $scripts; then
> +  echo "use \`test -f' instead of \`test -e'"
> +  status=false
> +fi
> +
> +# Check for uses of Xsed without corresponding echo "X
> +if $EGREP -n -e '\$Xsed' $scripts | $EGREP -v -n -e '\$ECHO \\*"X'; then
> +  echo "occurrences of \`\$Xsed\' without \`echo \"X\' on the same line"
> +  status=false
> +fi
> +
> +# Check for quotes within backquotes within quotes "`"bar"`"
> +if $EGREP -n -e '"[^`"]*`[^"`]*"[^"`]*".*`[^`"]*"' $scripts | \
> +   $EGREP -v "### testsuite: skip nested quoting test$"; then
> +  echo "nested quotes are dangerous"
> +  status=false
> +fi
> +

Re: [PATCH 2/2] Move portable shell tests from the old to the new testsuite.

[Charles Wilson]

On 9/17/2010 1:23 PM, Ralf Wildenhues wrote:
> And since IIRC
> Gary wanted to do the release this weekend, I wonder whether this isn't
> more safely pushed to after the relase.  WDYT?

FWIW, I agree that this patch should be postponed until after the
release.  I'm agnostic on whether tests -- such as this one -- should be
moved from the old test suite to the new one.  It's not as if the old
test suite will EVER go away, is it, since it serves as a collection of
demos.  OTOH, the "new test suite" is a nicer framework all around...

--
Chuck

Re: [PATCH] Document libtool variable to_host_file_cmd.

[Ralf Wildenhues]

Hi Charles,

* Charles Wilson wrote on Fri, Sep 17, 2010 at 06:28:46PM CEST:
> * doc/libtool.texi (libtool script contents:to_host_file_cmd): Document
> variable.
> (libtool script contents:to_tool_file_cmd): Prefer `build platform'
> to `build system'; Ditto `host platform'.

> OK to push?

OK.  Why the  s/system/platform/ changes though?  I see that
libtool.texi uses platform a lot, and also uses system quite a bit but
not quite as often.  Other GNU documentation I think prefers system
however.  Or are you trying to make a distinction between both terms?
In that case, they should probably be defined somewhere (and I'd venture
to say that they are not good terms to try to differentiate, because
most users will not think there could be a difference).

Thanks,
Ralf

> --- a/doc/libtool.texi
> +++ b/doc/libtool.texi
> @@ -6822,11 +6822,21 @@ Linker flag (passed through the C compiler) used to 
> generate thread-safe
>  libraries.
>  @end defvar
>  
> +...@defvar to_host_file_cmd
> +If the toolchain is not native to the build platform (e.g.@: if you are using
> +MSYS to drive the scripting, but are using the MinGW native Windows compiler)
> +this variable describes how to convert file names from the format used by the
> +build platform to the format used by host platform.  Normally set to
> +...@samp{func_convert_file_noop}, libtool will autodetect most cases in which
> +other values should be used.  On rare occasions, it may be necessary to 
> override
> +the autodetected value (@pxref{Cygwin to MinGW Cross}).
> +...@end defvar
> +
>  @defvar to_tool_file_cmd
> -If the toolchain is not native to the build system (e.g.@: if you are using
> +If the toolchain is not native to the build platform (e.g.@: if you are using
>  some Unix to drive the scripting together with a Windows toolchain running
>  in Wine) this variable describes how to convert file names from the format
> -used by the build system to the format used by the toolchain.  Normally set
> +used by the build platform to the format used by the toolchain.  Normally set
>  to @samp{func_convert_file_noop}.
>  @end defvar

Re: [PATCH] Document libtool variable to_host_file_cmd.

[Charles Wilson]

On 9/17/2010 1:30 PM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Fri, Sep 17, 2010 at 06:28:46PM CEST:
>> OK to push?
> 
> OK.  Why the  s/system/platform/ changes though?  I see that
> libtool.texi uses platform a lot, and also uses system quite a bit but
> not quite as often.  Other GNU documentation I think prefers system
> however.  Or are you trying to make a distinction between both terms?

Yes, the GNU Build System is already mentioned (with an xref to the
definition in another manual).  It refers to the whole
autoconf/automake/libtool process flow, as distinct from imake or scons
or whatever.

IMO, using 'build system' to refer to the $build platform could be
confused with that term.

If other GNU documentation uses the same phrase to mean two different
things, that doesn't mean we should do so as well.

> In that case, they should probably be defined somewhere (and I'd venture
> to say that they are not good terms to try to differentiate, because
> most users will not think there could be a difference).

We don't have a choice; the GNU Build System has already been given that
name by others, and we can't change that.  Our only choice is whether to
use a term that could be confused with it: 'build system' or not.  I say
not, whenever possible -- but I'm not doctrinaire about it. I'm not
about to go thru all of libtool.texi with a red pen, changing 'build
system' everywhere I see it...but to_host_file_cmd and to_tool_file_cmd
are so similar -- and defvar'ed so close together, that I thought they
should use similar terminology.

--
Chuck

Re: [PATCH] Document libtool variable to_host_file_cmd.

[Ralf Wildenhues]

* Charles Wilson wrote on Fri, Sep 17, 2010 at 07:37:23PM CEST:
> On 9/17/2010 1:30 PM, Ralf Wildenhues wrote:
> > OK.  Why the  s/system/platform/ changes though?  I see that
> > libtool.texi uses platform a lot, and also uses system quite a bit but
> > not quite as often.  Other GNU documentation I think prefers system
> > however.  Or are you trying to make a distinction between both terms?
> 
> Yes, the GNU Build System is already mentioned (with an xref to the
> definition in another manual).  It refers to the whole
> autoconf/automake/libtool process flow, as distinct from imake or scons
> or whatever.

Oh, you're right.  Hmm, difference in "GNU" prefix and in capitalization
...  ;-)

> IMO, using 'build system' to refer to the $build platform could be
> confused with that term.
> 
> If other GNU documentation uses the same phrase to mean two different
> things, that doesn't mean we should do so as well.

True, but 'build system' as referring to the thing the compiler runs on
is fairly enshrined terminology in the GNU toolchain (GCC, binutils,
etc).  I don't think there is a chance that will get replaced anytime.

Actually, I'm having a deja vu.  We discussed this before I guess.

> > In that case, they should probably be defined somewhere (and I'd venture
> > to say that they are not good terms to try to differentiate, because
> > most users will not think there could be a difference).
> 
> We don't have a choice; the GNU Build System has already been given that
> name by others, and we can't change that.  Our only choice is whether to
> use a term that could be confused with it: 'build system' or not.  I say
> not, whenever possible -- but I'm not doctrinaire about it. I'm not
> about to go thru all of libtool.texi with a red pen, changing 'build
> system' everywhere I see it...but to_host_file_cmd and to_tool_file_cmd
> are so similar -- and defvar'ed so close together, that I thought they
> should use similar terminology.

OK agreed.  Let's take the patch as it is, at least 'platform' is hard to
misunderstand, too.

Thanks,
Ralf

Re: [PATCH] Document libtool variable to_host_file_cmd.

[Charles Wilson]

On 9/17/2010 1:30 PM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Fri, Sep 17, 2010 at 06:28:46PM CEST:
>> OK to push?
> 
> OK.

Pushed.

--
Chuck

Re: [PATCH] Fix order of PATH manipulation in cwrapper and shwrapper

[Ralf Wildenhues]

* Charles Wilson wrote on Fri, Sep 17, 2010 at 06:23:28PM CEST:
> * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src:main): Call
> lt_update_exe_path before lt_update_lib_path, to ensure that the
> temporary rpath values (which include the OBJDIRs of uninstalled
> libtool libraries) precede installation and final -rpath directories.
> (func_emit_wrapper): Prepend $dllsearchpath to PATH before prepending
> $temp_rpath to $shlibpath_var; similar rationale as above.
> Reported by Jon Turney 

This is OK.  I mention a nit below.

Thanks,
Ralf

> --- a/libltdl/config/ltmain.m4sh
> +++ b/libltdl/config/ltmain.m4sh
> @@ -3293,6 +3293,22 @@ func_exec_program ()
>  
>if test -f \"\$progdir/\$program\"; then"
>  
> + # fixup the dll searchpath if we need to.
> + #
> + # For Windows, this must occur prior to any manipulation of
> + # $shlibpath (which, ON Windows, is PATH).  That way, we ensure
> + # that the $dllsearchpath value is prepended to $PATH first, and
> + # that the temporary rpath values (which contain the actual
> + # location of uninstalled DLLs, in their respective OBJDIR
> + # directories) are prepended second.  This ensures that just-built
> + # uninstalled libraries supersede installed ones.

I'd much rather have a short comment here,

  # Fix the DLL searchpath if we need to.  Do this before prepending to
  # $shlibpath, because on Windows, both are PATH and uninstalled
  # libraries must come first.

and have testsuite exposure that guarantees us that we won't regress,
and that, almost like an image, says more than thousand words.  ;-)

It's ok with me if the test patch comes later (due to release schedule).
If you like, I can write a test, it ought to be fairly simple.

> + if test -n "$dllsearchpath"; then
> +   $ECHO "\
> +# Add the dll search path components to the executable PATH
> +PATH=$dllsearchpath:\$PATH
> +"
> + fi
> +
>   # Export our shlibpath_var if we have one.
>   if test "$shlibpath_overrides_runpath" = yes && test -n 
> "$shlibpath_var" && test -n "$temp_rpath"; then
> $ECHO "\
> @@ -3307,14 +3323,6 @@ func_exec_program ()
>  "
>   fi
>  
> - # fixup the dll searchpath if we need to.
> - if test -n "$dllsearchpath"; then
> -   $ECHO "\
> -# Add the dll search path components to the executable PATH
> -PATH=$dllsearchpath:\$PATH
> -"
> - fi
> -
>   $ECHO "\
>  if test \"\$libtool_execute_magic\" != \"$magic\"; then
># Run the actual program with our arguments.
> @@ -3703,8 +3711,13 @@ EOF
>  
>lt_setenv ("BIN_SH", "xpg4"); /* for Tru64 */
>lt_setenv ("DUALCASE", "1");  /* for MSK sh */
> -  lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE);
> +  /* For Windows, this order is important: it ensures that the $dllsearchpath
> + value is prepended first, and that the temporary rpath values (which
> + contain the actual location of uninstalled DLLs, in their respective
> + OBJDIR directories) are prepended second.  This ensures that just-built
> + uninstalled libraries supersede installed ones. */

See above.

>lt_update_exe_path (EXE_PATH_VARNAME, EXE_PATH_VALUE);
> +  lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE);
>  
>lt_debugprintf (__FILE__, __LINE__, "(main) lt_argv_zero: %s\n",
> nonnull (lt_argv_zero));

Re: [PATCH] Fix order of PATH manipulation in cwrapper and shwrapper

[Charles Wilson]

On 9/17/2010 2:12 PM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Fri, Sep 17, 2010 at 06:23:28PM CEST:
>> * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src:main): Call
>> lt_update_exe_path before lt_update_lib_path, to ensure that the
>> temporary rpath values (which include the OBJDIRs of uninstalled
>> libtool libraries) precede installation and final -rpath directories.
>> (func_emit_wrapper): Prepend $dllsearchpath to PATH before prepending
>> $temp_rpath to $shlibpath_var; similar rationale as above.
>> Reported by Jon Turney 
> 
> This is OK.  I mention a nit below.

Pushed:

with this
# Fix the DLL searchpath if we need to.  Do this before prepending
# to shlibpath, because on Windows, both are PATH and uninstalled
# libraries must come first.

and this
/* Update the DLL searchpath.  EXE_PATH_VALUE ($dllsearchpath) must
   be prepended before (that is, appear after) LIB_PATH_VALUE ($temp_rpath)
   because on Windows, both *_VARNAMEs are PATH but uninstalled
   libraries must come first. */
which isn't really shorter than the previous version, but is probably a
little more clear, and models the new shwrapper commentary more closely.


I won't be able to do the test case before the release, especially not
today...

--
Chuck

LTO: consistently accept -fwhopr* and -flto* for GCC.

[Ralf Wildenhues]

We were inconsistent in matching flags matching -flto?* or -fwhopr?*
(in glob notation); GCC has more flags matching either.  It seems fairly
safe to allow all of these through.

On the other hand, from looking at the semantics it seems like the right
thing to _not_ allow through -fwhole-program for shared library creation
as that flag will let GCC think the library represents the whole program
and may radically optimize away everything, e.g., when there is no entry
point like main.

Pushed to the lto branch, merged into master.

Cheers,
Ralf

LTO: consistently accept -fwhopr* and -flto* for GCC.

* libltdl/config/ltmain.m4sh (func_mode_link): Accept -fwhopr*.
* libltdl/m4/libtool.m4 (_LT_SYS_HIDDEN_LIBDEPS): Also match
-flto*.

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 5ada0c1..d74b598 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -5014,10 +5014,10 @@ func_mode_link ()
   # @fileGCC response files
   # -tp=*Portland pgcc target processor selection
   # --sysroot=*  for sysroot support
-  # -O*, -flto*, -fwhopr, -fuse-linker-plugin GCC link-time optimization
+  # -O*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time optimization
   -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
   
-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \
-  -O*|-flto*|-fwhopr|-fuse-linker-plugin)
+  -O*|-flto*|-fwhopr*|-fuse-linker-plugin)
 func_quote_for_eval "$arg"
arg="$func_quote_for_eval_result"
 func_append compile_command " $arg"
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 01cd66a..c2803cd 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -6836,7 +6836,7 @@ _LT_EOF
 
 _lt_libdeps_save_CFLAGS=$CFLAGS
 case "$CC $CFLAGS " in #(
-*\ -flto\ *) CFLAGS="$CFLAGS -fno-lto" ;;
+*\ -flto*\ *) CFLAGS="$CFLAGS -fno-lto" ;;
 *\ -fwhopr*\ *) CFLAGS="$CFLAGS -fno-whopr" ;;
 esac
 

Re: [PATCH] Copy over DLL_EXPORT handling from C to C++ for non-GCC on w32.

[Peter Rosin]

Den 2010-09-17 18:53 skrev Ralf Wildenhues:
> let the review sprint begin ...

Sorry for the late patches...

> Hi Peter,
> 
> * Peter Rosin wrote on Fri, Sep 17, 2010 at 04:18:55PM CEST:
>> I noticed that -DDLL_EXPORT didn't appear when I compiled C++ code
>> with MSVC.
>>
>> I'd like this one to go in before the release.
>>
>> Ok to push?
> 
> OK, thanks.

Pushed. Thanks!

> Testsuite exposure would be nice at some point.

Yes. It would, I guess exceptions.at will cover it if I get that to work.

> In this macro, there are 4 cases, with the first criterion being decided
> at autoconf time, the second at configure time:
> 1)  $1 = CXX$CXX = yes
> 2)  $1 = CXX$CXX != yes
> 3)  $1 != CXX   $GCC = yes
> 4)  $1 != CXX   $GCC != yes
> 
> your code fixes case (2).  After the change, the mingw bits of
> the cases (1) and (2) both superfluously compare $1 to GCJ; that is
> not needed, because $1 is CXX.  You may simplify both cases accordingly.

There's also the cegcc in the $GCC = yes case, which looks like a paradox.
I didn't want to touch that at this stage though.

Cheers,
Peter

Re: [PATCH 1/2] * tests/sh.test: Detect missing 'test' in 'if "$foo" = ...'.

[Peter Rosin]

Den 2010-09-17 19:06 skrev Ralf Wildenhues:
> * Peter Rosin wrote on Fri, Sep 17, 2010 at 12:37:07PM CEST:
>> Subject: [PATCH 1/2] * tests/sh.test: Detect missing 'test' in 'if "$foo" = 
>> ...'.
> 
> OK, but I find the log entry not really explaining the change.
> How about this instead?
> 
> tests: actually detect missing 'test' in 'if "$foo" = ...'.
> 
> * tests/sh.test: Remove extra backslash in regex.

Pushed with your changelog, thanks!

Cheers,
Peter

Re: w32 pending?

[Roumen Petrov]

Ralf Wildenhues wrote:

Hi Charles,

* Charles Wilson wrote on Thu, Sep 16, 2010 at 08:47:52PM CEST:

[cygwin|mingw] Fix order of PATH manipulation in cwrapper

* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src:main): Call
lt_update_exe_path before lt_update_lib_path, to ensure that the local
OBJDIR(s) supersedes any -rpath directories.
Reported by Jon Turney<...>


This looks ok, but wouldn't the shell wrapper need this as well,
seeing that it could be run on w32 too (IIRC)?

Also, of course, testsuite exposure should follow eventually.

Thanks,
Ralf


--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -3677,8 +3677,12 @@ EOF

lt_setenv ("BIN_SH", "xpg4"); /* for Tru64 */
lt_setenv ("DUALCASE", "1");  /* for MSK sh */
-  lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE);
+  /* For Windows, this order is important: it ensures that any -rpath
+ values are prepended first, and then the local OBJDIR directory(ies)
+ is prepended second -- ensuring that just-built libraries supersede
+ installed ones. */
lt_update_exe_path (EXE_PATH_VARNAME, EXE_PATH_VALUE);
+  lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE);

lt_debugprintf (__FILE__, __LINE__, "(main) lt_argv_zero: %s\n",
   nonnull (lt_argv_zero));





+1 This will fix the case reported 
"http://lists.gnu.org/archive/html/bug-libtool/2009-12/msg00037.html"; - 
the report is with attached test case.


Roumen

Re: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.

[Roumen Petrov]

Hi Peter,

Peter Rosin wrote:

Hi!

need_lib_prefix.at currently fails with MSVC.


Hmm probably test fail as shared library is build without -no-undefined 
 flag.


Did libtool MSC allow creation of shared libraries without -no-undefined ?

On windows platforms (msc, gcc(mingw*)) may be the test require some 
PATH magics.

(as example like func_fix_path from static.at test)



I think the test
is there to ensure that "weird" systems continue to work even
if the testsuite is running on a "normal" system. "weird" in
this case are systems with need_lib_prefix set to "unknown" and
"normal" are those with it set to "no". However, there are
even weirder systems where need_lib_prefix should perhaps be
set to "never" (i.e. MSVC) but that currently simply sets it
to "no". "never" would perhaps be more appropriate since preopen
doesn't work right if libs have a lib prefix.




I think OS/2 is
affected in the same way as MSVC, but I have no means to test
that.

The below patch makes the need_lib_prefix.at test skip for the
even weirder systems, i.e. those where libname_spec does not
prefix library names with lib.


The test use libtool -module flag and thus libtool won't complain if 
library is created without "lib" prefix.



Ok to push?


No if -no-undefined  and PATH magic resolve failure in this test.

[SNIP]


Roumen

Re: [PATCH] maint: improve README instructions for fetching latest version.

[Gary V. Vaughan]

On 17 Sep 2010, at 00:24, Ralf Wildenhues wrote:
> Hi Gary,

Hallo Ralf,

> * Gary V. Vaughan wrote on Thu, Sep 16, 2010 at 04:49:47AM CEST:
>> * README, README-alpha (Obtaining the Latest Sources): New
>> section, describing use of savannah repositories and bootstrap.
>> * README.alpha (Reporting Bugs): Remove git instructions in
>> favour of a reference to the new `Obtaining the Latest Sources'
>> section.
>> 
>> Okay to push?
> 
> Sure, with a couple of nits addressed.

Oops.  Thanks for the review.  Pushed.

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)


PGP.sig
Description: This is a digitally signed message part

README cleanups

[Gary V. Vaughan]

With the recent additions I made to README, I noticed that we're
maintaining a lot of duplicated redundant information, and also that
README and README.alpha have needlessly drifted apart, effectively
hiding useful information from users of our alpha and stable release
tarballs.

All but the last patch in this series consolidate the differences
between these two files to make sure all the useful README details
are shipped in both alpha and stable releases.

At that point, the only difference remaining is the wording of the
very first paragraph - rather than having to make future additions
to both files, I've deleted README.alpha and replaced it with a
dist-time sed script which edits the README file in situ to contain
the alpha wording, along with a change to the Makefile dist-hook
rule to call it.

Tested by inspecting the contents of README in a tarball after
`make dist' with the AC_INIT version number set to 2.2.11a and 2.4.0
respectively.

Okay to push?

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)

[PATCH 3/6] maint: improve `Reporting Bugs' in README and README.alpha.

[Gary V. Vaughan]

* README (Reporting Bugs): Rewritten to a more complete and
concise guide to providing a good bug report.
* README.alpha (Reporting Bugs): Adjust to match.
---
 ChangeLog|5 +
 README   |   36 +++-
 README.alpha |   44 ++--
 3 files changed, 66 insertions(+), 19 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 9db58e1..2e04bda 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
 2010-09-18  Gary V. Vaughan  
 
+   maint: improve `Reporting Bugs' in README and README.alpha.
+   * README (Reporting Bugs): Rewritten to a more complete and
+   concise guide to providing a good bug report.
+   * README.alpha (Reporting Bugs): Adjust to match.
+
maint: consolidate Introductions of README and README.alpha.
* README (Introduction): Rewritten to a more logical order for
first time users, incorporating some additional text that was
diff --git a/README b/README
index acf8f8b..a40f96c 100644
--- a/README
+++ b/README
@@ -39,11 +39,37 @@ details.
 2. Reporting Bugs
 =
 
-If you have any suggestions or bug reports, or you wish to port Libtool
-to a new platform, please send electronic mail to the libtool mailing
-list  or bug reports to .  Be sure
-to send us your information from the end of the help message given by
-`./libtool --help'.
+If this distribution doesn't work for you, before you report the
+problem, at least try upgrading to the latest released version first,
+and see whether the issue persists.  If you feel able, you can also
+check whether the issue has been fixed in the development sources for
+the next release (see `Obtaining the Latest Sources' below).
+
+Once you've determined that your bug is still not fixed in the latest
+version, please send a full report to , including:
+
+  1. the information from the end of the help message given by
+ `./libtool --help', and the verbose output of any failed tests
+ (see `The Test Suites' immediately below);
+  2. complete instructions for how to reproduce your bug, along with
+ the results you were expecting, and how they differ from what you
+ actually see;
+  3. a workaround or full fix for the bug, if you have it;
+  4. a copy of `tests/testsuite.log' if you are experiencing failures
+ in the Autotest testsuite.
+  5. new test cases for the testsuite that demonstrate the bug are
+ especially welcome, and will help to ensure that future releases
+ don't reintroduce the problem - if you're not able to write a
+ complete testsuite case, a simple standalone shell script is
+ usually good enough to help us write a test for you.
+
+If you have any other suggestions, or if you wish to port Libtool to a
+new platform, please send email to the mailing list .
+
+Please note that if you send us an non-trivial code for inclusion in a
+future release, we may ask you for a copyright assignment (for brief
+details see the `Copyright Assignment' section on our `Contributing'
+webpage ).
 
 
 3. The Test Suites
diff --git a/README.alpha b/README.alpha
index 6f4ed3b..a8912a6 100644
--- a/README.alpha
+++ b/README.alpha
@@ -40,20 +40,36 @@ details.
 =
 
 If this distribution doesn't work for you, before you report the
-problem, please try upgrading to the latest version first (see
-`Obtaining the latest sources' below).
-
-The `bootstrap' script sets up the source directory for you to hack,
-though it may take quite some time to run.  If you don't intend to
-re-run the test suite, you can speed up the `bootstrap' step by an
-order of magnitude if you call it like this instead:
-
-  reconfdirs='. libltdl' ./bootstrap
-
-If your bug is still not fixed in the latest version, please send a full
-report to , including the information from the end
-of the help message given by `./libtool --help', and the verbose output
-of any failed test groups (as described below).
+problem, at least try upgrading to the latest released version first,
+and see whether the issue persists.  If you feel able, you can also
+check whether the issue has been fixed in the development sources for
+the next release (see `Obtaining the Latest Sources' below).
+
+Once you've determined that your bug is still not fixed in the latest
+version, please send a full report to , including:
+
+  1. the information from the end of the help message given by
+ `./libtool --help', and the verbose output of any failed tests
+ (see `The Test Suites' immediately below);
+  2. complete instructions for how to reproduce your bug, along with
+ the results you were expecting, and how they differ from what you
+ actually see;
+  3. a workaround or full fix for the bug, if you have it;
+  4. a copy of `tests/testuite.log' if you are experiencing failures
+ in the Autotest testsuite.
+  5. new test cases for the testsuite that demonstrate the bug are
+ e

[PATCH 2/6] maint: consolidate Introductions of README and README.alpha.

[Gary V. Vaughan]

* README (Introduction): Rewritten to a more logical order for
first time users, incorporating some additional text that was
previously only in README.alpha.
* README.alpha (Introduction): Adjust to match.
---
 ChangeLog|6 ++
 README   |   30 --
 README.alpha |   37 -
 3 files changed, 54 insertions(+), 19 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 3e1cb95..9db58e1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2010-09-18  Gary V. Vaughan  
 
+   maint: consolidate Introductions of README and README.alpha.
+   * README (Introduction): Rewritten to a more logical order for
+   first time users, incorporating some additional text that was
+   previously only in README.alpha.
+   * README.alpha (Introduction): Adjust to match.
+
maint: copy the Version Numbering section into README.alpha.
* README.alpha (Version Numbering): No less useful for users
of alpha releases.  Copied from README.
diff --git a/README b/README
index 16328bb..acf8f8b 100644
--- a/README
+++ b/README
@@ -8,22 +8,32 @@ This is GNU Libtool, a generic library support script.  
Libtool hides
 the complexity of using shared libraries behind a consistent, portable
 interface.
 
-To use Libtool, add the new generic library building commands to your
-Makefile, Makefile.in, or Makefile.am.  See the documentation for
-details.
-
 Libtool's home page is:
 
-  http://www.gnu.org/software/libtool/libtool.html
+http://www.gnu.org/software/libtool/libtool.html
 
 See the file NEWS for a description of recent changes to Libtool.
 
-See the file INSTALL for generic instructions on how to build and install
-Libtool.  Please see the file doc/notes.txt for some platform-specific
-information.  Please note that you need GNU make to build Libtool.
+See the file INSTALL for generic instructions on how to build and
+install Libtool.  Please see the file doc/notes.txt for some platform-
+specific information.  Please note that you need GNU make to build
+Libtool.
+
+See the info node (libtool)Tested Platforms. (or the file doc/PLATFORMS)
+for a list of platforms that Libtool already supports.
 
-See the info node (libtool)Tested Platforms. (or the file
-doc/PLATFORMS) for a list of platforms that Libtool supports.
+Please try it on all the platforms you have access to:
+
+ * If it builds and passes the test suite (`gmake check'), please send
+   a short note to the libtool mailing list  with a
+   subject line including the string `[PLATFORM]', and containing the
+   details from the end of `./libtool --help' in the body.
+ * Otherwise, see `Reporting Bugs' below for how to help us fix any
+   problems you discover.
+
+To use Libtool, add the new generic library building commands to your
+Makefile, Makefile.in, or Makefile.am.  See the documentation for
+details.
 
 
 2. Reporting Bugs
diff --git a/README.alpha b/README.alpha
index 8c72c03..6f4ed3b 100644
--- a/README.alpha
+++ b/README.alpha
@@ -4,17 +4,36 @@ GNU Libtool
 1. Introduction
 ===
 
-This is an alpha testing release of GNU Libtool, please try it on all
-the platforms you have access to.  Using it more or less implicitly
-signs you up to help us find whatever problems you report.
+This is an alpha testing release of GNU Libtool, a generic library
+support script.  Libtool hides the complexity of using shared libraries
+behind a consistent, portable interface.
 
-See the file INSTALL for generic instructions on how to build and install
-Libtool.  Please see the file doc/notes.txt for some platform-specific
-information.  Please note that you need GNU make to build Libtool.
+Libtool's home page is:
 
-If it builds and passes the test suite (`gmake check'), please send
-notification to the libtool mailing list  with a
-subject line including the string `[PLATFORM]'.
+http://www.gnu.org/software/libtool/libtool.html
+
+See the file NEWS for a description of recent changes to Libtool.
+
+See the file INSTALL for generic instructions on how to build and
+install Libtool.  Please see the file doc/notes.txt for some platform-
+specific information.  Please note that you need GNU make to build
+Libtool.
+
+See the info node (libtool)Tested Platforms. (or the file doc/PLATFORMS)
+for a list of platforms that Libtool already supports.
+
+Please try it on all the platforms you have access to:
+
+ * If it builds and passes the test suite (`gmake check'), please send
+   a short note to the libtool mailing list  with a
+   subject line including the string `[PLATFORM]', and containing the
+   details from the end of `./libtool --help' in the body.
+ * Otherwise, see `Reporting Bugs' below for how to help us fix any
+   problems you discover.
+
+To use Libtool, add the new generic library building commands to your
+Makefile, Makefile.in, or Makefile.am.  See the documentation for
+details.
 
 
 2. Reporting Bugs
-- 
1.7.2.2

[PATCH 4/6] maint: reformat README `The Test Suites' for consistency.

[Gary V. Vaughan]

* README (The Test Suites): Reformatted for consistency.
* README.alpha (The Test Suites): Adjust to match.
---
 ChangeLog|4 
 README   |   38 --
 README.alpha |   39 +--
 3 files changed, 49 insertions(+), 32 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 2e04bda..25c23db 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
 2010-09-18  Gary V. Vaughan  
 
+   maint: reformat README `The Test Suites' for consistency.
+   * README (The Test Suites): Reformatted for consistency.
+   * README.alpha (The Test Suites): Adjust to match.
+
maint: improve `Reporting Bugs' in README and README.alpha.
* README (Reporting Bugs): Rewritten to a more complete and
concise guide to providing a good bug report.
diff --git a/README b/README
index a40f96c..efd678d 100644
--- a/README
+++ b/README
@@ -79,15 +79,15 @@ Libtool comes with two integrated sets of tests to check 
that your build
 is sane.  You can run both test suites like this, assuming that `gmake'
 refers to GNU make:
 
-  gmake -k check
+gmake -k check
 
 If you want to run the old testsuite only, do it like this:
 
-  gmake check TESTSUITEFLAGS=-V
+gmake check TESTSUITEFLAGS=-V
 
 If you want to run the new testsuite only, do it like this:
 
-  gmake check-local
+gmake check-local
 
 The tests of the old test suite run in groups in the various demo
 subdirectories, so if one of the tests early in a group FAILs, the rest
@@ -100,9 +100,8 @@ To run a test group of the old test suite in isolation 
(say, you think
 you have fixed a bug, but don't want to rerun the entire suite), you can
 do it like this:
 
-  gmake check TESTS="tests/cdemo-static.test tests/cdemo-static-make.test \
- tests/cdemo-static-exec.test" \
-  TESTSUITEFLAGS=-V
+gmake check TESTSUITEFLAGS=-V TESTS="tests/cdemo-static.test \
+tests/cdemo-static-make.test tests/cdemo-static-exec.test"
 
 Providing that you have a FAIL from the most recent group from a
 particular demo directory (like the cdemo-static.test group above), you
@@ -118,37 +117,40 @@ the verbose output from all failed tests.
 In order to enable debug shell tracing, you can set VERBOSE=debug when
 running the old test suite.
 
+In the long run, Libtool will move to using only the new, Autotest-
+driven testsuite.  Its usage is documented in:
 
-In the long run, Libtool will move to using only the new,
-Autotest-driven testsuite.  Its usage is documented in
+info Autoconf 'testsuite Invocation'
 
-  info Autoconf 'testsuite Invocation'
+but simple help may also be obtained through:
 
-but simple help may also be obtained through
-
-  gmake check-local TESTSUITEFLAGS='--help'
+gmake check-local TESTSUITEFLAGS='--help'
 
 For verbose output, add the flag `-v', for running only a subset of the
 independent tests, merely specify them by number or by keyword, both of
 which are displayed with the `--list' flag.  For example, the `libtool'
 keyword is used for the tests that exercise only this script.  So it is
 possible to test an installed script, possibly from a different Libtool
-release, with
-  gmake check-local TESTSUITEFLAGS="-k libtool LIBTOOL=/path/to/libtool"
+release, with:
+
+gmake check-local \
+TESTSUITEFLAGS="-k libtool LIBTOOL=/path/to/libtool"
 
 Some tests, like the one exercising max_cmd_len limits, make use of this
 to invoke the testsuite recursively on a subset of tests.  For these
 tests, the variable INNER_TESTSUITEFLAGS may be used.  It will be
-expanded right after the `-k libtool', without separating whitespace,
-so that further limiting of the recursive set of tests is possible.
-For example, to run only the template tests within the max_cmd_len, use
-  gmake check-local TESTSUITEFLAGS="-v -x -k max_cmd_len \
+expanded right after the `-k libtool', without separating whitespace, so
+that further limiting of the recursive set of tests is possible.  For
+example, to run only the template tests within the max_cmd_len, use:
+
+gmake check-local TESTSUITEFLAGS="-v -x -k max_cmd_len \
  INNER_TESTSUITEFLAGS=',template -v -x'"
 
 If you wish to report test failures to the libtool list, you need to
 send the file `tests/testsuite.log' to the bug report mailing list,
 .
 
+
 4. Obtaining the Latest Sources
 ===
 
diff --git a/README.alpha b/README.alpha
index a8912a6..5082ed3 100644
--- a/README.alpha
+++ b/README.alpha
@@ -79,15 +79,15 @@ Libtool comes with two integrated sets of tests to check 
that your build
 is sane.  You can run both test suites like this, assuming that `gmake'
 refers to GNU make:
 
-  gmake -k check
+gmake -k check
 
 If you want to run the old testsuite only, do it like this:
 
-  gmake check TESTSUITEFLAGS=-V
+gmake check TESTSUITEFLAGS=-V
 
 If you want to run the new testsuite only, do it like this:
 
-  gmake check-local
+

[PATCH 5/6] maint: improve README's `Obtaining the Latest Sources'.

[Gary V. Vaughan]

* README (Obtaining the Latest Sources): Add instructions for
obtaining stable, alpha and nightly snapshot tarballs.
* README.alpha (Obtaining the Latest Sources): Adjust to match.
---
 ChangeLog|5 +
 README   |   56 +++-
 README.alpha |   56 +++-
 3 files changed, 115 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 25c23db..a4781d9 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
 2010-09-18  Gary V. Vaughan  
 
+   maint: improve README's `Obtaining the Latest Sources'.
+   * README (Obtaining the Latest Sources): Add instructions for
+   obtaining stable, alpha and nightly snapshot tarballs.
+   * README.alpha (Obtaining the Latest Sources): Adjust to match.
+
maint: reformat README `The Test Suites' for consistency.
* README (The Test Suites): Reformatted for consistency.
* README.alpha (The Test Suites): Adjust to match.
diff --git a/README b/README
index efd678d..21bfe21 100644
--- a/README
+++ b/README
@@ -154,6 +154,52 @@ send the file `tests/testsuite.log' to the bug report 
mailing list,
 4. Obtaining the Latest Sources
 ===
 
+* With the exception of ancient releases, all official GNU Libtool
+  releases have a detached GPG signature file.  With this you can verify
+  that the corresponding file (i.e. without the `.sig' suffix) is the
+  same file that was released by the owner of it's GPG key ID.  First,
+  be sure to download both the .sig file and the corresponding release,
+  then run a command like this:
+
+gpg --verify libtool-x.y.z.tar.gz.sig
+
+  If that command fails because you don't have the required public key,
+  then run this command to import it:
+
+gpg --keyserver keys.gnupg.net --recv-keys 2983D606
+
+  and then rerun the `gpg --verify' command.
+
+* Official stable releases of GNU Libtool, along with these detached
+  signature files are available from:
+
+ftp://ftp.gnu.org/gnu/libtool
+
+  To reduce load on the main server, please use one of the mirrors
+  listed at:
+
+http://www.gnu.org/order/ftp.html
+
+* Alpha quality pre-releases of GNU Libtool, also with detached
+  signature files are available from:
+
+ftp://alpha.gnu.org/gnu/libtool
+
+  and some of the mirrors listed at:
+
+http://www.gnu.org/order/ftp.html
+
+* Nightly snapshots of the unreleased development trunk of GNU Libtool
+  are available from:
+
+http://pogma.com/libtool
+
+  These files do not have signatures, but will allow you to easily
+  determine whether the most recent development code still exhibits any
+  bugs you have discovered, without requiring you to install a complete
+  build environment and the extra tools needed to bootstrap a version
+  control checkout.
+
 * The master libtool repository is stored in git.
 
   If you are a member of the savannah group for GNU Libtool, a writable
@@ -195,6 +241,14 @@ send the file `tests/testsuite.log' to the bug report 
mailing list,
   - Autoconf 2.59 or later
   - Automake 1.9.6 or later
 
+* The `bootstrap' script sets up the source directory for you to hack,
+  though it may take quite some time to run.  If you don't intend to
+  re-run the test suite, you can speed up the `bootstrap' step by an
+  order of magnitude if you call it like this instead:
+
+reconfdirs='. libltdl' ./bootstrap
+
+
 5. Version Numbering
 
 
@@ -250,7 +304,7 @@ things:
 For more details about version numbers, see:
 
 http://www.gnu.org/software/libtool/contribute.html
--- 
+--
   Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
   Foundation, Inc.
   Written by Gary V. Vaughan, 2004
diff --git a/README.alpha b/README.alpha
index 5082ed3..1771124 100644
--- a/README.alpha
+++ b/README.alpha
@@ -154,6 +154,52 @@ send the file `tests/testsuite.log' to the bug report 
mailing list,
 4. Obtaining the Latest Sources
 ===
 
+* With the exception of ancient releases, all official GNU Libtool
+  releases have a detached GPG signature file.  With this you can verify
+  that the corresponding file (i.e. without the `.sig' suffix) is the
+  same file that was released by the owner of it's GPG key ID.  First,
+  be sure to download both the .sig file and the corresponding release,
+  then run a command like this:
+
+gpg --verify libtool-x.y.z.tar.gz.sig
+
+  If that command fails because you don't have the required public key,
+  then run this command to import it:
+
+gpg --keyserver keys.gnupg.net --recv-keys 2983D606
+
+  and then rerun the `gpg --verify' command.
+
+* Official stable releases of GNU Libtool, along with these detached
+  signature files are available from:
+
+ftp://ftp.gnu.org/gnu/libtool
+
+  To reduce load on the main server, please use one of the mirrors
+  listed at:
+
+http://www.gnu.org/order/ftp.html
+
+* Alpha quality pre-release

[PATCH 6/6] maint: use sed instead of maintaining 2 README files.

[Gary V. Vaughan]

* README.alpha: Deleted.  It was mostly identical to README.
* libltdl/config/edit-readme-alpha: New script to edit the
contents of README in the dist tree prior to tarring up.
* Makefile.am (dist-hook): Run it before rolling alpha release
tarball.
---
 ChangeLog|7 +
 Makefile.am  |   11 +-
 README.alpha |  324 --
 libltdl/config/edit-readme-alpha |   49 ++
 4 files changed, 63 insertions(+), 328 deletions(-)
 delete mode 100644 README.alpha
 create mode 100755 libltdl/config/edit-readme-alpha

diff --git a/ChangeLog b/ChangeLog
index a4781d9..05c4466 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,12 @@
 2010-09-18  Gary V. Vaughan  
 
+   maint: use sed instead of maintaining 2 README files.
+   * README.alpha: Deleted.  It was mostly identical to README.
+   * libltdl/config/edit-readme-alpha: New script to edit the
+   contents of README in the dist tree prior to tarring up.
+   * Makefile.am (dist-hook): Run it before rolling alpha release
+   tarball.
+
maint: improve README's `Obtaining the Latest Sources'.
* README (Obtaining the Latest Sources): Add instructions for
obtaining stable, alpha and nightly snapshot tarballs.
diff --git a/Makefile.am b/Makefile.am
index dcd0876..6e29a29 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -406,6 +406,10 @@ install-data-local: libltdl/Makefile.in
 ## Distribution. ##
 ## - ##
 
+edit_readme_alpha = $(auxdir)/edit-readme-alpha
+
+EXTRA_DIST += $(edit_readme_alpha)
+
 uninstall-hook:
@$(NORMAL_UNINSTALL)
@list='$(ltdldatafiles) $(auxfiles)'; for f in $$list; do \
@@ -419,11 +423,10 @@ uninstall-hook:
done
 
 dist-hook:
-## Ship README.alpha only in alpha release, but renamed to README
-   @if test -f $(srcdir)/README.alpha; then \
+## Edit the README file for alpha releases.
case $(VERSION) in \
- *[a-z]) cp -p $(srcdir)/README.alpha $(distdir)/README ;; \
-   esac; else :; fi
+ *[a-z]) $(SHELL) $(srcdir)/$(edit_readme_alpha) $(distdir)/README ;; \
+   esac
 ## Ensure aclocal has not wrongly picked up old macro definitions.
for macro in LT_INIT AC_PROG_LIBTOOL AM_PROG_LIBTOOL; do \
  if grep $$macro $(srcdir)/aclocal.m4 $(srcdir)/libltdl/aclocal.m4; 
then \
diff --git a/README.alpha b/README.alpha
deleted file mode 100644
index 1771124..000
--- a/README.alpha
+++ /dev/null
@@ -1,324 +0,0 @@
-GNU Libtool
-***
-
-1. Introduction
-===
-
-This is an alpha testing release of GNU Libtool, a generic library
-support script.  Libtool hides the complexity of using shared libraries
-behind a consistent, portable interface.
-
-Libtool's home page is:
-
-http://www.gnu.org/software/libtool/libtool.html
-
-See the file NEWS for a description of recent changes to Libtool.
-
-See the file INSTALL for generic instructions on how to build and
-install Libtool.  Please see the file doc/notes.txt for some platform-
-specific information.  Please note that you need GNU make to build
-Libtool.
-
-See the info node (libtool)Tested Platforms. (or the file doc/PLATFORMS)
-for a list of platforms that Libtool already supports.
-
-Please try it on all the platforms you have access to:
-
- * If it builds and passes the test suite (`gmake check'), please send
-   a short note to the libtool mailing list  with a
-   subject line including the string `[PLATFORM]', and containing the
-   details from the end of `./libtool --help' in the body.
- * Otherwise, see `Reporting Bugs' below for how to help us fix any
-   problems you discover.
-
-To use Libtool, add the new generic library building commands to your
-Makefile, Makefile.in, or Makefile.am.  See the documentation for
-details.
-
-
-2. Reporting Bugs
-=
-
-If this distribution doesn't work for you, before you report the
-problem, at least try upgrading to the latest released version first,
-and see whether the issue persists.  If you feel able, you can also
-check whether the issue has been fixed in the development sources for
-the next release (see `Obtaining the Latest Sources' below).
-
-Once you've determined that your bug is still not fixed in the latest
-version, please send a full report to , including:
-
-  1. the information from the end of the help message given by
- `./libtool --help', and the verbose output of any failed tests
- (see `The Test Suites' immediately below);
-  2. complete instructions for how to reproduce your bug, along with
- the results you were expecting, and how they differ from what you
- actually see;
-  3. a workaround or full fix for the bug, if you have it;
-  4. a copy of `tests/testuite.log' if you are experiencing failures
- in the Autotest testsuite.
-  5. new test cases for the testsuite that demonstrate the bug are
- especially welcome, and will help to ensure that future releases
- d

[PATCH 1/6] maint: copy the Version Numbering section into README.alpha.

[Gary V. Vaughan]

* README.alpha (Version Numbering): No less useful for users
of alpha releases.  Copied from README.
---
 ChangeLog|6 ++
 README.alpha |   56 
 2 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index d72d9e0..3e1cb95 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-09-18  Gary V. Vaughan  
+
+   maint: copy the Version Numbering section into README.alpha.
+   * README.alpha (Version Numbering): No less useful for users
+   of alpha releases.  Copied from README.
+
 2010-09-17  Peter Rosin  
 
tests: actually detect missing 'test' in 'if "$foo" = ...'.
diff --git a/README.alpha b/README.alpha
index a58167e..8c72c03 100644
--- a/README.alpha
+++ b/README.alpha
@@ -148,6 +148,62 @@ send the file `tests/testsuite.log' to the bug report 
mailing list,
   or optionally with:
   - Autoconf 2.59 or later
   - Automake 1.9.6 or later
+
+5. Version Numbering
+
+
+People have complained that they find the version numbering scheme under
+which libtool is released confusing... so we've changed it!
+
+It works like this:
+
+   .
+
+Releases with a  less than 1 were not yet feature
+complete.  Releases with a  of 1 used the old numbering
+scheme that everyone disliked so much.  Releases with a 
+of 2 us the new scheme described here.  If libtool ever undergoes a
+major rewrite or substantial restructuring, the  will be
+incremented again.
+
+If we make a patch release to fix bugs in a stable release, we use a
+third number, so:
+
+  ..
+
+Version numbers are chosen to make it easy for users to decide two
+things:
+
+  Q: How `developed' is this release?
+  A: The higher the number, the better!
+  Q: How `stable' is this release?
+  A: - If the  is even, it is a stable release, `2.0'.
+ - If the  is odd, it is a development version with
+   new features compared to the last stable release, `2.1a'.
+ - If it has an `odd'[1] letter after the version number,  it is a
+   snapshot direct from CVS, `2.1a'.
+ - If it has an `even'[1] letter after the version number, it is an
+   alpha quality release, `2.1b'.
+ - If it has three numbers in the version, it is a patch release,
+   fixing bugs from the stable release (with no new features), `2.0.1'.
+
+[1] We always increment the letter in the repository before *and* after
+making a release tarball.  This means that "odd" letters
+(a,c,e,g...) only exist in the repository, and "even" letters are
+used instantaneously for an alpha release.  Since the odd lettered
+version numbers cover many states of the tree, we also qualify them
+by adding the cvs version of the ChangeLog:
+
+$ libtool --version
+ltmain.sh (GNU libtool 1.1603 2004/09/12 22:02:07) 2.1a
+
+Copyright (C) 2004  Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+For more details about version numbers, see:
+
+http://www.gnu.org/software/libtool/contribute.html
 -- 
   Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
   Foundation, Inc.
-- 
1.7.2.2

Re: README cleanups

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Sat, Sep 18, 2010 at 07:20:12AM CEST:
> Okay to push?

I'm fine with this patch series.  Thanks.

A minor nit: users don't really need GNU make to build Libtool from a
release tarball unless they want to do VPATH builds.  This was stated
before your patch though.  (For a git checkout, I think GNU make may be
necessary.)  The INSTALL file should already warn about non-GNU make and
VPATH anyway.

Cheers,
Ralf

Re: [PATCH 6/6] maint: use sed instead of maintaining 2 README files.

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Sat, Sep 18, 2010 at 07:20:18AM CEST:
> * README.alpha: Deleted.  It was mostly identical to README.
> * libltdl/config/edit-readme-alpha: New script to edit the
> contents of README in the dist tree prior to tarring up.
> * Makefile.am (dist-hook): Run it before rolling alpha release
> tarball.

For what it's worth ...

> --- /dev/null
> +++ b/libltdl/config/edit-readme-alpha

> +for file in "$@"; do
> +  trap 'x=$?; rm $file.T; exit $x' 1 2 13 15
> +
> +  sed -e '/^This is GNU Libtool,/,/^interface.$/c\
> +This is an alpha testing release of GNU Libtool, a generic library\
> +support script.  Libtool hides the complexity of using shared libraries\
> +behind a consistent, portable interface.' $file > $file.T \

this script will wrongly exit with status 0 if the stdout redirection
fails at this point.

> +&& mv -f $file.T $file
> +
> +  test -f $file.T && {
> +rm $file.T
> +echo "$0: unable to edit $file"
> +exit 1
> +  }
> +done
> +
> +exit 0

Cheers,
Ralf

Re: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.

[Peter Rosin]

Den 2010-09-18 00:04 skrev Roumen Petrov:
> Hi Peter,
> 
> Peter Rosin wrote:
>> Hi!
>>
>> need_lib_prefix.at currently fails with MSVC.
> 
> Hmm probably test fail as shared library is build without -no-undefined  flag.
> 
> Did libtool MSC allow creation of shared libraries without -no-undefined ?
> 
> On windows platforms (msc, gcc(mingw*)) may be the test require some PATH 
> magics.
> (as example like func_fix_path from static.at test)

You are barking up the wrong tree, since:

1. The test passes on MinGW and Cygwin with gcc, if wouldn't do that if
   -no-undefined was the cause of the fail.
2. The patch in the old quoted message makes the test pass on MSVC, which
   it wouldn't do if -no-undefined was the cause of the fail.

"PATH magic" is not relevant if -no-undefined is not passed, since everything
should be static in that case (no dlls created).

Cheers,
Peter