OSDN Git Service

fix gdb+python build failure if using non-GNU sed
authorbrobecke <brobecke>
Wed, 2 Feb 2011 04:36:15 +0000 (04:36 +0000)
committerbrobecke <brobecke>
Wed, 2 Feb 2011 04:36:15 +0000 (04:36 +0000)
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.

gdb/ChangeLog
gdb/configure
gdb/configure.ac

index 84013cb..7e95941 100644 (file)
@@ -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.
index 5a6d0be..5ee5ce6 100755 (executable)
 
   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*)
 
index 68b0838..d2b75f6 100644 (file)
@@ -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,