Windows Debugging w/o MS

["Martin v. Löwis"]

> I am trying to build an extension module written in C++ on windows XP.
> I am trying to use only open-source tools, such as mingw. I'm using
> the Python 2.5 official, and it seems to compile my module just fine
> (I'm using the --compiler=mingw32). I can also import the module. The
> problem is, when I attempt to use it, I get a segfault.

Does it segfault if you import it, or just when you invoke functions
of the module?

You should get it in a state where you can import it just fine, e.g.
by removing stuff from the init function.

> Now, I'm
> pretty sure this segfault is just a bug in my C++ code. So of course,
> I would like to debug this thing somehow. I tried using the mingw gdb
> giving it my python.exe to run, but obviously this python has no debug
> info, and wasn't even compiled with mingw. I was hoping it would still
> somehow debug my extension module right, but when I do a backtrace
> after it segfaults, I get nothing useful.

If you can import safely, you should do this:
1. start gdb, with python.exe as the program
2. r(un) it, in gdb
3. import your_module
4. Ctrl-c (or otherwise get back into the debugger)
5. see whether you can set breakpoints on your function

gdb should be able to figure out that your extension module was
loaded and has debug information. Set a breakpoint and see whether
it shows line numbers. If it doesn't, it's because your module does
not have debug information.

> I've tried compiling python from source, and my extension module,
> using MSVC8 (free express version), and I managed to get this to work.
> The thing is, I don't want to have to recompile every single python
> package I need (wxPython, SciPy, etc).

You should also be able to compile Python with the mingw compiler,
giving you gdb debug information for all modules.

> So basically, I need some general advice for how to compile and debug
> extension modules on windows using only open-source tools. I am still
> amazed that MSVC7.1 was chosen for the official python release and not
> mingw, has anyone explained this?

Python uses the "system compiler" on all systems, and the system
compiler on Microsoft Windows, is, well, Microsoft C.

Using that compiler works better in a number of important use cases.
For example, it is absolutely necessary to be able to compile
extension modules that use C++, COM, and the Microsoft Foundation
Classes. Such extension modules must be compiled with MSC, since
g++ is not capable of compiling them (at least for MFC). One
important extension module that relies on such technology is
Mark Hammond's PythonWin.

If Python was build with mingw, it might be that such modules could
not work anymore, depending on how precisely the mingw build is
done (e.g. what CRT you would use).

Regards,
Martin