[Patches] [ python-Patches-462754 ] no '_d' ending for mingw32
noreply@sourceforge.net
noreply@sourceforge.net
Sat, 09 Mar 2002 03:44:09 -0800
Patches item #462754, was opened at 2001-09-19 05:29
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470
Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Nobody/Anonymous (nobody)
Summary: no '_d' ending for mingw32
Initial Comment:
This patch prevents distutils from naming the extension
modules <extname>_d.pyd when compiled with mingw32 on
Windows in debug mode. Instead, the extension modules
will get the normal name <extname>.pyd. Technically,
the patch doesn't prevent the behaviour for mingw32,
but only adds the _d for MS Visual C++ and Borland
compilers (though I don't know about the Borland case).
The reason for this? Adding "_d" doesn't make any sense
for GNU compilers. I think it's just a MS Visual C++
madness. If you want to debug an extension module that
was compiled with gcc, you have to use gdb anyway,
because the debugging symbols of MSVC++ and gcc are
incompatible. So you normally use a release Python
version (from the python.org binary download) and
compile your extensions with mingw32.
To put it shortly:
The current state is that you do a
"setup.py build --compiler=mingw32 --debug" and then
rename the extension modules, removing the _d. Then
fire up gdb to debug your module.
With this patch, the renaming isn't necessary anymore.
----------------------------------------------------------------------
>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-09 12:44
Message:
Logged In: YES
user_id=21627
Does the patch actually work? It seems to me that, if
compiled with-pydebug, import will automatically search for
the _d version, and complain if it is not found.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-01-04 12:52
Message:
Logged In: YES
user_id=21627
The rationale for using the debugging version of MSVCRT are
not the debugging information alone, but also the additional
functionalities, like heap consistency checks and other
assertions. So it is not obvious that you do not want to use
the debugging version of this library in a debug build.
----------------------------------------------------------------------
Comment By: Gerhard Häring (ghaering)
Date: 2002-01-04 03:50
Message:
Logged In: YES
user_id=163326
mingw links with msvcrt.dll. I've plans to add mingw32
support to the autoconf build process (hopefully soon enough
for 2.3).
The GNU and MS debugger symbols are incompatible, though, so
I think that mingw32 shouldn't link to the debug version of
msrcrt (gdb doesn't understand the Microsoft debugger
symbols; and the Visual Studio debugger has no idea what the
debugging symbols of gcc are all about; isn't cross-platform
and cross-compiler programming fun?).
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-12-30 14:13
Message:
Logged In: YES
user_id=21627
How does the mingw port interact with the debugging
libraries? With MSVC, the debug build will link to the debug
versions of the CRT. What C library will mingw link with (I
hope it won't use crtdll.dll)?
----------------------------------------------------------------------
Comment By: Gerhard Häring (ghaering)
Date: 2001-09-28 23:28
Message:
Logged In: YES
user_id=163326
Yes. But mingw32 isn't emulating Unix under Windows (that
would be Cygwin). It's just a version of gcc and friends
that targets native win32. It links against msvcrt (not a
Posix emulation library like Cygwin does).
This is a bit hypothetical because I didn't yet hack the
autoconf build process for native win32 with mingw32.
Currently, you cannot build a complete Python with mingw32,
but you *can* build extension modules against an existing
Python (compiled with M$ VC++).
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-09-28 22:43
Message:
Logged In: YES
user_id=31435
All else being equal, a system emulating Unix under Windows
should strive to make life comfortable for Unix folks. The
question is thus whether all else is in fact equal <wink --
but I don't know, as I don't yet use the system under
discussion>.
----------------------------------------------------------------------
Comment By: Gerhard Häring (ghaering)
Date: 2001-09-28 20:37
Message:
Logged In: YES
user_id=163326
Hmm. I don't like the _d endings at all. But if the policy
on win32 is that debug executables and libraries get a "_d"
ending, then I'm unsure wether this patch should be applied.
I have plans to hack the autoconf madness to build a native
win32 Python with mingw32. But that won't be ready by
tomorror. And I don't think that I'll add "_d" endings there
for debugging, because that would be inconsistent with the
normal autoconf builds on Unix.
I'm glad that *I* don't have to decide wether this patch is
a Good Thing. Being consistent with Python win32 build or
with GNU (gcc/autoconf). Take your pick :-)
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-09-19 05:46
Message:
Logged In: YES
user_id=31435
FYI, MSVC never adds _d on its own -- Mark Hammond and/or
Guido forced it to do that. I don't remember why, but one
of them explained it to me long ago and it made good sense
at the time <wink>.
MSCV normally compiles debug and release builds into
distinct subdirectories, and uses the same names in both.
But *our* MSVC setup forces it to compile both flavors of
build directly into the PCbuild directory, so has to give
the resulting DLLs and executables different names (else
the second build would overwrite the results of the first
build).
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470