Do not pass -DNDEBUG to Python compilations in development mode
authorTom Tromey <tom@tromey.com>
Sun, 16 Sep 2018 18:38:12 +0000 (12:38 -0600)
committerTom Tromey <tom@tromey.com>
Mon, 17 Sep 2018 19:51:38 +0000 (13:51 -0600)
The Python CFLAGS include -DNDEBUG.  This was apparently done
intentionally -- setting the flags is done manually because, according
to a comment, python-config passes too many things to the compiler
(which is true).

Per PR python/20445, this patch changes configure so that -DNDEBUG is
only used by release builds.  This probably doesn't have very much
effect in practice, but I did see that some Python headers use assert,
so perhaps it will give some safety.

Tested by rebuilding and re-running gdb.python/*.exp on x86-64 Fedora 28.

gdb/ChangeLog
2018-09-17  Tom Tromey  <tom@tromey.com>

PR python/20445:
* configure: Rebuild.
* configure.ac: Conditionally use -DNDEBUG for Python.

gdb/ChangeLog
gdb/configure
gdb/configure.ac

index 43c4753860e1897dabed22cf43c5224679a333ec..e984f53a6675b270144e93037077f524a7065a46 100644 (file)
@@ -1,3 +1,9 @@
+2018-09-17  Tom Tromey  <tom@tromey.com>
+
+       PR python/20445:
+       * configure: Rebuild.
+       * configure.ac: Conditionally use -DNDEBUG for Python.
+
 2018-09-17  Tom Tromey  <tom@tromey.com>
 
        * configure: Rebuild.
index e011b77414ba108e06561180092da5760739eb0e..a5d6e747e783cae5e5895b9478727f1ea29efc22 100755 (executable)
@@ -10762,7 +10762,11 @@ $as_echo "#define HAVE_PYTHON 1" >>confdefs.h
   # would make the python-related objects be compiled differently from the
   # rest of GDB (e.g., -O2 and -fPIC).
   if test "${GCC}" = yes; then
-    tentative_python_cflags="-fno-strict-aliasing -DNDEBUG -fwrapv"
+    tentative_python_cflags="-fno-strict-aliasing -fwrapv"
+    # Python headers recommend -DNDEBUG, but it's unclear if that just
+    # refers to building Python itself.  In release mode, though, it
+    # doesn't hurt for the Python code in gdb to follow.
+    $development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG"
   fi
 
   if test "x${tentative_python_cflags}" != x; then
index f658da84e325a7feb4b8d11b260f0f20028bb306..66fc6c633f3f96b056de9c9a9a802ce7ebc43b25 100644 (file)
@@ -965,7 +965,11 @@ if test "${have_libpython}" != no; then
   # would make the python-related objects be compiled differently from the
   # rest of GDB (e.g., -O2 and -fPIC).
   if test "${GCC}" = yes; then
-    tentative_python_cflags="-fno-strict-aliasing -DNDEBUG -fwrapv"
+    tentative_python_cflags="-fno-strict-aliasing -fwrapv"
+    # Python headers recommend -DNDEBUG, but it's unclear if that just
+    # refers to building Python itself.  In release mode, though, it
+    # doesn't hurt for the Python code in gdb to follow.
+    $development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG"
   fi
 
   if test "x${tentative_python_cflags}" != x; then