is all the available swig+python+mingw compile inf

I'm trying to build a C++ extension for python using swig. I've followed the instructions below and the others to a T and can't seem to get my extension to load.

I ran across this article on the MinGW site under "How do I create Python extensions?"

http://www.mingw.org/wiki/FAQ

I also found these tutorials:

http://boodebr.org/main/python/build-windows-extensions http://www.mail-archive.com/modwsgi@googlegroups.com/msg04655.html http://oldwiki.mingw.org/index.php/Python%20extensions

I'm using Panda3d-1.7.0 to build against - panda on win32 is running python2.6.4 (MSC v.1500 compiled). I'm using MinGW gcc/g++ (GCC) 3.4.5 to compile.

I've noticed that when I run setup.py with the following command:

python setup.py build -cmingw32

gcc.exe runs first, then g++.exe to build the pyd. g++ is linking against: -lpython26 -lmsvcr90

she builds and links well enough (no errors) but, when I copy the _extension.pyd and extension.py files over into Panda3d-1.7.0\python\Lib\site-packages and run > python -c "import extension" from the command line, Python dumps the following:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Panda3D-1.7.0\python\Lib\site-packages\extension.py", line 25, in <module>
    _bullet = swig_import_helper()
  File "C:\Panda3D-1.7.0\python\Lib\site-packages\extension.py", line 21, in swig_import_helper
    _mod = imp.load_module('_extension', fp, pathname, description)
ImportError: DLL load failed: The specified module could not be found.

Any tips or pointers? Thanks!

Two things to verify:

Check the C runtime library DLL bound to your python and to your extension DLL with dependency walker to make sure that they are using the same CRT. This is a common source of trouble when building extensions for other languages. (I see it often with Lua, for instance) and can cause interesting and intermittent bugs that are particularly difficult to track down.
IIRC, the "official" Python releases for Windows have switched to Visual Studio Express from MinGW. This may make it nearly impossible to use MinGW to build a C++ extension that can be called from a Python compiled and linked with Visual Studio due to irreconcilable differences in the C++ ABI.

Both of these add up to advice to make sure that the ABI you are assuming in your extension DLL matches the ABI assumed by the hosting application, and that you aren't duplicating fundamental functional blocks such as the CRT that might contain or manage state that is difficult to correctly share between instances.

Edit: The improved edit of the question speaks strongly to there being issues with mismatches between Microsoft's C++ ABI and the GCC C++ ABI which are known to differ.