Issue462754
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2001-09-19 03:29 by ghaering, last changed 2022-04-10 16:04 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
distutils-mingw32-debug.dif | ghaering, 2001-09-19 03:29 |
Messages (12) | |||
---|---|---|---|
msg37673 - (view) | Author: Gerhard Häring (ghaering) * | Date: 2001-09-19 03:29 | |
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. |
|||
msg37674 - (view) | Author: Tim Peters (tim.peters) * | Date: 2001-09-19 03:46 | |
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). |
|||
msg37675 - (view) | Author: Gerhard Häring (ghaering) * | Date: 2001-09-28 18:37 | |
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 :-) |
|||
msg37676 - (view) | Author: Tim Peters (tim.peters) * | Date: 2001-09-28 20:43 | |
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>. |
|||
msg37677 - (view) | Author: Gerhard Häring (ghaering) * | Date: 2001-09-28 21:28 | |
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++). |
|||
msg37678 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2001-12-30 13:13 | |
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)? |
|||
msg37679 - (view) | Author: Gerhard Häring (ghaering) * | Date: 2002-01-04 02:50 | |
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?). |
|||
msg37680 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-01-04 11:52 | |
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. |
|||
msg37681 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-03-09 11:44 | |
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. |
|||
msg37682 - (view) | Author: Gerhard Häring (ghaering) * | Date: 2002-04-17 05:07 | |
Logged In: YES user_id=163326 If python.exe is compiled --with-pydebug, then this is true. But the point is that I want to compile debug versions of my extension modules and use them with the standard python.exe (*not* python_d.exe). So yes, the patch does work, at least it did when I submitted it <wink>. |
|||
msg37683 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-07-28 11:20 | |
Logged In: YES user_id=21627 This patch is wrong: Whether or not _d should be added to the module name depends on whether or not Py_DEBUG is defined; this is independent on whether --debug was given, atleast for Cygwin (for MSVC, --debug will define _DEBUG which will define Py_DEBUG). So the current distutils is wrong (since it always adds _d), but the patch doesn't make it better (since it never adds _d). Rejecting the patch. |
|||
msg37684 - (view) | Author: A.M. Kuchling (akuchling) * | Date: 2002-11-06 15:28 | |
Logged In: YES user_id=11375 Is there any way to get the setting of the Py_DEBUG flag from Python code? I can't see any; if there was a way to detect this setting, couldn't the patch be trivially modified to be correct? |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:04:27 | admin | set | github: 35200 |
2001-09-19 03:29:12 | ghaering | create |