This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
GDB Python extension on AIX
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Wed, 10 Aug 2016 21:55:54 -0400
- Subject: GDB Python extension on AIX
- Authentication-results: sourceware.org; auth=none
When Python is installed correctly on AIX and the GDB configuration
process finds Python, some of the source files that implement the GDB
Python extension fail to compile on AIX with the following error:
In file included from
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/6.1.0/include/c++/math.h:36:0,
from build-gnulib/import/math.h:27,
from /opt/freeware/include/python2.7/pyport.h:325,
from /opt/freeware/include/python2.7/Python.h:58,
from /home/dje/src/binutils-gdb/gdb/python/python-internal.h:9
,
from /home/dje/src/binutils-gdb/gdb/python/python.c:94:
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/6.1.0/include/c++/cmath:640:11:
error: '::isnan' has not been declared
using ::isnan;
^~~~~
Makefile:2593: recipe for target 'python.o' failed
This is due to a Python extension header redefining feature test
macros in the compiler namespace that interfere with AIX math.h and
libstdc++ math.h behavior
gdb/python/python-internal.h includes the following fragment:
/* Python 2.4 doesn't include stdint.h soon enough to get {u,}intptr_t
needed by pyport.h. */
/* /usr/include/features.h on linux systems will define _POSIX_C_SOURCE
if it sees _GNU_SOURCE (which config.h will define).
pyconfig.h defines _POSIX_C_SOURCE to a different value than
/usr/include/features.h does causing compilation to fail.
To work around this, undef _POSIX_C_SOURCE before we include Python.h.
Same problem with _XOPEN_SOURCE. */
#undef _POSIX_C_SOURCE
#undef _XOPEN_SOURCE
Redefining and undefining feature test macros, such as _POSIX_C_SOURCE
and _XOPEN_SOURCE are not very wise things to do, especially in the
middle of a sequence of includes that already may have included other
system header files with conditionals that were affected by the macros
in their original state.
If I comment out this unfortunate fragment, GDB is able to compile on
AIX with the Python extension.
Is this fragment necessary for other targets? Would the GDB community
at least be open to a proposal to bracket this fragment with
#ifndef _AIX
...
#endif
?
What is the preferred way to address this?
Thanks, David