This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: py-breakpoint.c fails to compile with MinGW GCC
- From: Phil Muldoon <pmuldoon at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb at sourceware dot org
- Date: Thu, 28 Jul 2011 15:54:18 +0100
- Subject: Re: py-breakpoint.c fails to compile with MinGW GCC
- References: <E1QmPMV-0007CR-Tf@fencepost.gnu.org>
- Reply-to: pmuldoon at redhat dot com
Eli Zaretskii <eliz@gnu.org> writes:
> The error message is:
>
> ./python/py-breakpoint.c:1019: error: initializer element is not constant
> ./python/py-breakpoint.c:1019: error: (near initialization for `breakpoint_objec t_type.tp_new')
>
> This is with MinGW GCC 3.4.2 (yes, old, but it worked fine for me
> until now).
>
> I have Python 2.7.1 installed on that machine.
>
> Removing the last element of the initializer, i.e. this line:
>
> PyType_GenericNew /* tp_new */
>
> allows py-breakpoint.c to compile.
>
> Is this a bug in GCC, in GDB, in Python, or in my setup?
>
> TIA
There was a patch for this:
http://sourceware.org/ml/gdb-patches/2010-09/msg00214.html
Specifically from that email:
"- I have to modify some gdb python files because the files 'python-function.c', python-cmd.c (...) define some 'static PyTypeObject'.
The field 'tp_new' of these static variables is statically initialized with the python 'PyType_GenericNew' function.
In Windows port of Python, this function is declared as a dllimport one and cannot be copied at compilation time in a static variable.
For these files, I modified the source code
- to initialize the 'tp_new' fields to '0' in the static variables and
- to affect the proper 'PyType_GenericNew' value in the 'gdbpy_initialize_commands', 'gdbpy_initialize_frames' (...). "
It does not seem to have been checked in, even though it was reviewed.
I'm also unsure why some folks can compile ok (Dan in that email
mentions he has been), and some can't.
Cheers
Phil