Hello,

Just in case someone else would like to build their GDB with Python
support enable on MinGW. This is Work In Progress, and is only shared
here in the hopes that it might be useful.

This is also to share some of the obstacles I've faced, and the way
I have solved them, for now.

  1. The python install has a completely different layout on Windows,
     compared to Unix platforms.
       a. python.exe is in the root directory
       b. the python library in the <root>/Lib directory
          and is named libpython27.a (not '.' in the version number,
          unlike on Unix where it's libpython2.7.a).  Note that despite
          the .a filename extension, it's NOT an archive (it sorta points
          to the DLL, so at the end GDB is linked against the DLL which
          is in the <root> directory).
       c. python includes are in <root>/include

  2. python-config.py is broken on Windows.
     The immediate issue is that some sysconfig variables are missing,
     and I think that this is because Python was not built using
     the standard configure/make procedure

Resolutions:

  1a: Easy - if python is not in <root>/bin, then try <root>.

  1b: Not an issue once we've dealt with 2.

  1c: We cannot continue including the Python files using
      #include "python-2.7/Python.h" anymore, since the `python-2.7'
      subdirectory does not exist in the Windows install.
      We were using a non-standard approach thanks to some configury
      that edited the python include path used when compiling.
      So I removed that piece of configury and changed all the includes.

      This opens the door for unexpected conflicts, given the filenames
      chosen by the Python implementation.  And sure enough, had a
      "cute" issue: GDB has gdb/python/python.h, and Python has
      <root>/include/Python.h.  The Windows filesystem being case
      insensitve, GCC started picking up gdb/python/python.h when
      we meant to include Python.h.

      I fixed that by renaming python.h into gdb-python.h.

  2. For now, I wrote my own python-wconfig.py program, which works
     for windows and by-passes the unix one.  I don't know whether this
     is the best decision in the long term, or not, but it allowed me
     to side-step issues such as backslashes, paths with drive letters
     in them, etc, when mixing a cygwin environment to do the build,
     with a MinGW compiler.  I will see how ugly the the hacking on
     python-config.py turns out to be.

Problems still not fixed:

  . The HAVE_LIBPYTHON2_x macros are currently not set, because of
    the fact that libpython2.7.a is missing a dot in the version number.
    Easily fixable, just ugly.

  . This was suggested by Doug:
    Change the compilation arguments such that the python include path
    is last.  In case of conflict, the compiler should pick the non-python
    file.

With this patch applied, I was able to build GDB with Python, and
obtain something that seems to work:

        (gdb) python import time
        (gdb) python print time.clock()
        1.50167540471e-06
        (gdb) 

The one caveat is that it seems that Python does not like being
installed in a non-standard location.  Even if I did not move it
after GDB was build, GDB aborts early during the call to Py_initialize
after having printed the following message:

        $ ./gdb/gdb
        ImportError: No module named site

The ImportError happens much before the GDB code is called, I'm assuming
during Python DLL mapping, since the following program reproduces the same
issue.

        #include "Python.h"
        #include "stdio.h"
        
        int
        main (void)
        {
          printf ("Initializing Python...\n");
          Py_SetProgramName ("[...]/python.exe");
          Py_Initialize ();
          printf ("+++ done.\n");
          return 0;
        }

So I had to start GDB with the following command:

        PYTHONPATH=/[...]/python/Lib ./gdb/gdb
-- 
Joel