From: Phil Muldoon <pmuldoon@redhat.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb@sourceware.org
Subject: Re: py-breakpoint.c fails to compile with MinGW GCC
Date: Thu, 28 Jul 2011 14:54:00 -0000 [thread overview]
Message-ID: <m3vcumzc9x.fsf@redhat.com> (raw)
In-Reply-To: <E1QmPMV-0007CR-Tf@fencepost.gnu.org> (Eli Zaretskii's message of "Thu, 28 Jul 2011 08:06:47 -0400")
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
next prev parent reply other threads:[~2011-07-28 14:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-28 12:07 Eli Zaretskii
2011-07-28 14:54 ` Phil Muldoon [this message]
2011-07-28 15:01 ` Tom Tromey
2011-07-28 15:19 ` Joel Brobecker
2011-07-28 15:37 ` Phil Muldoon
2011-07-28 15:44 ` Tom Tromey
2011-07-28 16:11 ` Kai Tietz
2011-07-28 16:17 ` Eli Zaretskii
2011-07-28 16:46 ` Tom Tromey
2011-07-28 17:07 ` Eli Zaretskii
2011-07-29 3:04 ` Chris Sutcliffe
2011-07-29 6:13 ` Eli Zaretskii
2011-07-28 16:13 ` Eli Zaretskii
2011-07-28 16:25 ` Joel Brobecker
2011-07-28 16:48 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3vcumzc9x.fsf@redhat.com \
--to=pmuldoon@redhat.com \
--cc=eliz@gnu.org \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox