It looks like part of r59290 resulted in /pdb:None always being part of
the ldflags_shared_debug list.  This means that there will be no debug
info stored for extensions built in debug mode, which kinda negates the
purpose of doing a debug build.  

Looking back at the revision history and comparing similar code in
msvccompiler.py it looks like the /pdb:None was optionally added in the
first place because of compatibility issues with earlier compilers.  For
MSVC 7 and 9 I think it should be fine to simply remove /pdb:None from
that list.  My ad hoc testing so far has not revealed any problems with
making this change.

Furthermore, /PDB:None is no more supported by VC2008 express.
You end up with files named "None"...

Since I am unfamiliar with MSVC, I will need to digg on this, so if
anyone can help on this : any idea on what would be the proper fix and
why ?

Like Robin, I think it's better to remove the /pdb option, and let the 
default behavior, which is (when /debug is present) to generate a .pdb 
file next to the generated target.

What are pdb files, by the way?

A .pdb is the "program database" that contain debug info, i.e. the mapping between assembler positions and source lines, the description of data structures, and other things that are necessary to debug a program.

Thanks for explaining.  Is someone willing to add a test in test_msvc9compiler?

/pdb:None initially did *not* mean "no debug information", but "no pdb file", see

http://msdn.microsoft.com/en-us/library/aa278542(VS.60).aspx

Debug information would be embedded to the DLL.

Later versions of the VS documentation fail to mention "None" as a special value. Assuming it still has its original semantics, I fail to see the bug in this report.

No, MSVC does not behave that way any longer.  Now it simply creates a file named "None", so I expect that the newer versions simply do not support writing the "old-style" debug info written to the DLL or EXE. If a setup script creates more than one extension module then they all overwrite that None file.

In order to get debug info in a useable form, distutils simply can not use /pdb:None.  By removing that option entirely then debug info is generated like normal into a *.pdb file and using the debugger to trace through the extension module's code will happily work correctly.

I've had to have this hack in wxPython's setup.py since Python 2.6 to work around this problem:


# Yet another distutils hack, this time for the msvc9compiler.  There
# is a bug in at least version distributed with Python 2.6 where it
# adds '/pdb:None' to the linker command-line, but that just results
# in a 'None' file being created instead of putting the debug info
# into the .pyd files as expected.  So we'll strip out that option via
# a monkey-patch of the msvc9compiler.MSVCCompiler.initialize method.

if os.name == 'nt' and  sys.version_info >= (2,6):
    import distutils.msvc9compiler
    _orig_initialize = distutils.msvc9compiler.MSVCCompiler.initialize

    def _initialize(self, *args, **kw):
        rv = _orig_initialize(self, *args, **kw)
        try:
            self.ldflags_shared_debug.remove('/pdb:None')
        except ValueError:
            pass
        return rv

    distutils.msvc9compiler.MSVCCompiler.initialize = _initialize

Ah ok, then removing the option sounds fine to me (not for 2.6, though).