fix gdb+python build failure if using non-GNU sed

Non-GNU sed do not like the '?' quantifier when used in a s/// regexp
that involve back-references, causing the build to fail when trying
to link with Python support. This fixes it by using the '*' quantifier
instead.

gdb/ChangeLog:

 	* configure.ac: Work around non-GNU sed limitation when computing
 	python version number.
 	* configure: Regenerate.

3 files changed, 38 insertions, 2 deletions

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 84013cba04..7e95941b47 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,9 @@
+2011-02-02  Joel Brobecker  <brobecker@adacore.com>
+
+	* configure.ac: Work around non-GNU sed limitation when computing
+	python version number.
+	* configure: Regenerate.
+
 2011-02-01  Jan Kratochvil  <jan.kratochvil@redhat.com>
 
 	Fix debug printing of TYPE_INSTANCE.
diff --git a/gdb/configure b/gdb/configure
index 5a6d0bed48..5ee5ce6db4 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -10658,8 +10658,23 @@ fi
 
   have_libpython=no
   if test "${have_python_config}" = yes; then
+    # Determine the Python version by extracting "-lpython<version>"
+    # part of the python_libs. <version> is usually X.Y with X and Y
+    # being decimal numbers, but can also be XY (seen on Windows).
+    #
+    # The extraction is performed using sed with a regular expression.
+    # Initially, the regexp used was using the '?' quantifier to make
+    # the dot in the version number optional.  Unfortunately, this
+    # does not work with non-GNU versions of sed because, because of
+    # what looks like a limitation (the '?' quantifier does not work
+    # with back-references).  We work around this limitation by using
+    # the '*' quantifier instead.  It means that, in theory, we might
+    # match unexpected version strings such as "-lpython2..7", but
+    # this seems unlikely in practice.  And even if that happens,
+    # an error will be triggered later on, when checking that version
+    # number.
     python_version=`echo " ${python_libs} " \
-                         | sed -e 's,^.* -l\(python[0-9]*[.]\?[0-9]*\).*$,\1,'`
+                         | sed -e 's,^.* -l\(python[0-9]*[.]*[0-9]*\).*$,\1,'`
     case "${python_version}" in
     python*)
 
diff --git a/gdb/configure.ac b/gdb/configure.ac
index 68b083865f..d2b75f6375 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -769,8 +769,23 @@ else
 
   have_libpython=no
   if test "${have_python_config}" = yes; then
+    # Determine the Python version by extracting "-lpython<version>"
+    # part of the python_libs. <version> is usually X.Y with X and Y
+    # being decimal numbers, but can also be XY (seen on Windows).
+    #
+    # The extraction is performed using sed with a regular expression.
+    # Initially, the regexp used was using the '?' quantifier to make
+    # the dot in the version number optional.  Unfortunately, this
+    # does not work with non-GNU versions of sed because, because of
+    # what looks like a limitation (the '?' quantifier does not work
+    # with back-references).  We work around this limitation by using
+    # the '*' quantifier instead.  It means that, in theory, we might
+    # match unexpected version strings such as "-lpython2..7", but
+    # this seems unlikely in practice.  And even if that happens,
+    # an error will be triggered later on, when checking that version
+    # number.
     python_version=`echo " ${python_libs} " \
-                         | sed -e 's,^.* -l\(python[[0-9]]*[[.]]\?[[0-9]]*\).*$,\1,'`
+                         | sed -e 's,^.* -l\(python[[0-9]]*[[.]]*[[0-9]]*\).*$,\1,'`
     case "${python_version}" in
     python*)
       AC_TRY_LIBPYTHON(${python_version}, have_libpython,