How does one get from "ImportError: DLL load failed:..." to a culprit .dll and symbol?

[Chris Cormie]

Gabriel Genellina wrote:
> En Mon, 23 Feb 2009 10:41:20 -0200, Chris Cormie 
> <ccormie at aussiemail.com.au> escribió:
> 
>>> If that not-very-technical description [all I've ever needed] doesn't
>>> help, you'll need to read the DW help file (HTFF1K) or wait till
>>> someone who knows what they are doing comes along :-)
>>
>> LOL, I am that person :p
>> Your technique works well and it does provide the information and it 
>> is a (roundabout) solution to this class of problems:  thank you very 
>> much. It doesn't answer the original question so I'll restate it:
>>
>> How do you get *Python* to tell you the dll and the problem symbol? 
>> Not external tools, Python. Python at a low level is calling 
>> LoadLibrary and GetProcAddress to resolve symbols and the call fails. 
>> At that point it has the name of the dll and the problem symbol to 
>> hand and yet strangely only gives an opaque error message. How does 
>> one get Python to print out the faulty DLL and symbol?
> 
> You can't, because it isn't Python who's trying to load the symbol - the 
> *only* symbol that Python attempts to import itself is "initFOO" from 
> FOO.pyd, and when that fails you get an explicit message.
> The error you see must come from the extension itself, and propagates 
> into Python as an ImportError.

Right -- now we are getting somewhere! That makes a lot of sense.

What I was expecting to see next was an explicit GetProcAddress() call 
in the extension code that was failing in initFOO() or elsewhere in the 
extension code. But there are no such calls.

I think what might have been making this confusing is that the root of 
my example problem is link time.

Let me explain by giving the specific example case I have to hand.
I orginally got on to this class of opaque runtime errors caused by 
missing symbols through building the pycURL extension on MinGW. As of 
Python 2.6, Python links against the new msvcr90.dll C Runtime. MinGW 
maintains a set of .a files for system DLLs including the C Runtime. 
When building pycURL naturally I want to link against libmsvcr90.a so 
Python 2.6 and pycURL are using the same C Rutime. Problem was, MinGW's 
  .a was wrong: it exports symbols that msvcr90.dll does not in fact 
possess. Building pycURL with the faulty libmsvcr90.a causes the opaque 
error message: "ImportError: DLL load failed"

Now I expected this meant an explict LoadLibrary() GetProcAddress() 
sequence was failing in the extension but perhaps that's not what 
happens at all?
Chris