From ae292b3afc0fce65c12014d2cc4621d7a0e661fd Mon Sep 17 00:00:00 2001 From: Tom Tromey Date: Sun, 16 Sep 2018 12:38:12 -0600 Subject: Do not pass -DNDEBUG to Python compilations in development mode 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 PR python/20445: * configure: Rebuild. * configure.ac: Conditionally use -DNDEBUG for Python. --- gdb/configure.ac | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'gdb/configure.ac') diff --git a/gdb/configure.ac b/gdb/configure.ac index f658da8..66fc6c6 100644 --- a/gdb/configure.ac +++ b/gdb/configure.ac @@ -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 -- cgit v1.1