Re: GDB 7.2 - Patch proposal for the use of GDB/Python scripts on MinGW

[Tom Tromey <tromey@redhat.com>]

>>>>> "Serge" == Serge CHATROUX <serge.chatroux@st.com> writes:

Serge> +   cmdpy_object_type.tp_new = PyType_GenericNew; #endif

Tom> Just make your patch do this unconditionally on all hosts, with a
Tom> little (one line -- not as long as what you have above) comment
Tom> explaining where it is needed.  I think that is clearer than using
Tom> #ifdef all over.

Serge> I do not know how to avoid the '#if __MINGW32__' because this
Serge> modification is not needed for other systems (Linux, cygwin).

You can just use the MinGW code everywhere.

Serge> It seems that Daniel Jacobowitz succeed in compiling gdb over
Serge> MINGW without this modification.

Yeah, I don't know about that.  But, from
http://docs.python.org/extending/newtypes.html:

    We’d like to just assign this to the tp_new slot, but we can’t, for
    portability sake, On some platforms or compilers, we can’t statically
    initialize a structure member with a function defined in another C
    module, so, instead, we’ll assign the tp_new slot in the module
    initialization function just before calling PyType_Ready():

So it seems your change might be needed at least sometimes.

Tom> Perhaps this code and some surrounding code should be refactored so
Tom> that we can just avoid FILE* and use the same code path on all
Tom> hosts.

Serge> It could be great. I don't know the name of the Python scripting
Serge> support maintainers. It could be great to have their feedback.

If you want to do it, it is fine.

Serge> I set this feature to solve an issue that I had on Linux:
Serge> - I compiled Python support without the --enabled-shared support. 

Ok.

How does Python usually work in this setup?

Serge> 	gdb
Serge> 	'import site' failed; use -v for traceback

It seems that we could catch this error and disable the python support
at that time.

This error is very misleading because "gdb -v" won't actually help.
Ugh.

Tom