FYI: WIP patch to build GDB with Python on MinGW
Joel Brobecker
brobecker@adacore.com
Fri Jan 21 05:57:00 GMT 2011
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python-migw32.diff
Type: text/x-diff
Size: 15792 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20110121/2c891058/attachment.bin>
More information about the Gdb-patches
mailing list