[issue4214] no extension debug info with msvc9compiler.py
Robin Dunn added the comment:
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
--
versions: +Python 2.6
___
Python tracker
<http://bugs.python.org/issue4214>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3432] Mac, 2.6 framework install error
New submission from Robin Dunn <[EMAIL PROTECTED]>: OSX Leopard (10.5.4) Python-2.6b2 tarball ./configure --enable-universalsdk --enable-framework make sudo make install Ends with this error: cd Mac && make installmacsubtree DESTDIR="" Creating directory /Library/Frameworks/Python.framework/Versions/2.6/Mac/Tools DYLD_FRAMEWORK_PATH=/projects/Python-2.6b2: arch -ppc -i386 ../python.exe ./scripts/cachersrc.py -v /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac /Library/Frameworks/Python.framework/Versions/2.6/Mac/Tools Traceback (most recent call last): File "./scripts/cachersrc.py", line 7, in import macresource File "/projects/Python-2.6b2/Lib/plat-mac/macresource.py", line 6, in from Carbon import Res File "/projects/Python-2.6b2/Lib/plat-mac/Carbon/Res.py", line 4, in from _Res import * ImportError: No module named _Res make[1]: *** [installmacsubtree] Error 1 make: *** [frameworkinstallmaclib] Error 2 Since by this time in the install process the _Res module has already been installed I was able to work around this issue by hacking the generated Mac/Makefile and setting RUNSHARED to nothing. The same problem happens in Mac/IDLE/Makefile as well. -- components: Macintosh messages: 70189 nosy: robind severity: normal status: open title: Mac, 2.6 framework install error type: compile error versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3432> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3433] Mac, 3.0 framework install error with fink cp
New submission from Robin Dunn <[EMAIL PROTECTED]>: OSX Leopard (10.5.4) Python-3.0b2 tarball ./configure --enable-universalsdk --enable-framework make sudo make install Ends with this error: cd PythonLauncher && make install DESTDIR= test -d "/Applications/Python 3.0" || mkdir -p "/Applications/Python 3.0" test -d "/Applications/Python 3.0/Python Launcher.app" && rm -r "/Applications/Python 3.0/Python Launcher.app" cp -r "Python Launcher.app" "/Applications/Python 3.0" touch "/Applications/Python 3.0/Python Launcher.app" test -d "/Applications/Python 3.0" || mkdir -p "/Applications/Python 3.0" test -d "/Applications/Python 3.0/IDLE.app" && rm -r "/Applications/Python 3.0/IDLE.app" make[1]: [install_IDLE] Error 1 (ignored) cp -PR IDLE/IDLE.app "/Applications/Python 3.0" cp: Warning: the meaning of `-P' will change in the future to conform to POSIX. Use `--parents' for the old meaning, and `--no-dereference' for the new one. ln -sf /Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python "/Applications/Python 3.0/IDLE.app/Contents/MacOS/Python" ln: creating symbolic link `/Applications/Python 3.0/IDLE.app/Contents/MacOS/Python' to `/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python': No such file or directory make[1]: *** [install_IDLE] Error 1 make: *** [frameworkinstallapps] Error 2 It looks like this is due to fink's cp being found first on the PATH. Temporarily disabling /sw/bin/cp so /bin/cp would be found first then the install finished. -- components: Macintosh messages: 70190 nosy: robind severity: normal status: open title: Mac, 3.0 framework install error with fink cp type: compile error versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3433> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3434] Mac, 3.0 framework install, Python.app not created
New submission from Robin Dunn <[EMAIL PROTECTED]>: OS X Leopard (10.5.4) Python-3.0b2 tarball ./configure --enable-universalsdk --enable-framework make sudo make install /Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app is not created by the install step, but it is needed for running python3.0: $ python3.0 python3.0: execv: /Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python: No such file or directory -- components: Macintosh messages: 70191 nosy: robind severity: normal status: open title: Mac, 3.0 framework install, Python.app not created type: compile error versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3434] Mac, 3.0 framework install, Python.app not created
Robin Dunn <[EMAIL PROTECTED]> added the comment: This appears to already be fixed in the current py3k branch, so this can be closed. Sorry for the noise. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3433] Mac, 3.0 framework install error with fink cp
Robin Dunn <[EMAIL PROTECTED]> added the comment: Maybe, but I think that a more proper approach would be one of the following: * Decide that features specific to Apple's cp are required and change the Makefile to use /bin/cp instead of just cp. * Use configure to determine if a GNU cp is present and if so adjust the command-line parameters used. * Just use the $(INSTALL) value already set by configure as already used in the main Makefile. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3433> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7812] Call to gestalt('sysu') on OSX can lead to freeze in wxPython apps
Changes by Robin Dunn : -- nosy: +robind ___ Python tracker <http://bugs.python.org/issue7812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8607] OSX: duplicate -arch flags in CFLAGS breaks sysconfig
New submission from Robin Dunn :
In Python 2.7b1, building on OSX 10.6 with this configure command:
export CC=gcc-4.0
export CXX=g++-4.0
export MACOSX_DEPLOYMENT_TARGET=10.4
../configure \
--with-universal-archs=32-bit \
--enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk \
--enable-framework
Results in these lines in Makefile:
BASECFLAGS= -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
-fno-common -dynamic
CFLAGS= $(BASECFLAGS) -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk $(OPT) $(EXTRA_CFLAGS)
Then later on in the build the sysconfig module uses the -arch flags in CFLAGS
but is not able to find a match because of the extra set of values, and the
build fails with this exception:
Traceback (most recent call last):
File "./../Lib/site.py", line 542, in
main()
File "./../Lib/site.py", line 521, in main
addbuilddir()
File "./../Lib/site.py", line 118, in addbuilddir
s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
File "/projects/Python-2.7b1/Lib/sysconfig.py", line 646, in get_platform
"Don't know machine value for archs=%r"%(archs,))
ValueError: Don't know machine value for archs=('i386', 'i386', 'ppc', 'ppc')
make: *** [sharedmods] Error 1
--
components: Build
messages: 104905
nosy: robind
priority: normal
severity: normal
status: open
title: OSX: duplicate -arch flags in CFLAGS breaks sysconfig
type: compile error
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue8607>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4214] no extension debug info with msvc9compiler.py
New submission from Robin Dunn <[EMAIL PROTECTED]>: 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. -- components: Distutils messages: 75264 nosy: robind severity: normal status: open title: no extension debug info with msvc9compiler.py type: compile error versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4214> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
New submission from Robin Dunn : This may have already been discussed but my searches didn't turn up anything concrete other than issue 4120 which is a similar but different problem. The problem I'm facing is that wxPython requires that version 6 of the common controls DLL be loaded in order for the GUI applications to use the themed version of the widgets on XP+ platforms, but it appears that this can only be done reliably if the manifest for the .exe is the one that specifies that version of the common controls assembly. Prior to 2.6 I was able to install python[w].exe.manifest files next to the python executables from my installer and it would work fine, but now that Python 2.6 is built with MSVC9 and it has its own manifest that does not always work. Initial testing seems to indicate that using an external manifest still works ok on 32-bit platforms, but not on the 64-bit versions of Windows. I've tried ensuring that the wxPython .pyd's and the wxWidgets DLLs have an internal manifest that specifies the common controls assembly but that has not helped. The only thing I've been able to find that works for both 32 and 64 bit is to replace the internal manifest in python.exe with a new one that specifies both the CRT and the Common Controls assemblies, but that is obviously a Bad Thing for the install of an extension module to do, so I'm opening this issue to look for alternatives. So, does anybody have any experience or ideas on how to enable the wxPython extensions to load the new common controls assembly without needing to change the stock Python executables' manifest? If not, are there any objections to adding the common controls assembly to the stock manifest used for python.exe and pythonw.exe? -- components: Build, Windows messages: 80308 nosy: robind severity: normal status: open title: Specifying common controls DLL in manifest type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
Robin Dunn added the comment: If I understand correctly then setting an activation context won't help because by the time that an extension module is loaded the choice of which version of the common controls DLL will be loaded has already been made, and it may in fact already be loaded. The system must be told at the time that the .exe is loaded which common controls DLL it wants, otherwise it will use the old non-themed version. Everything I've tried seems to confirm this, if that is not true I'd love to see some examples. ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
Robin Dunn added the comment: Ok, the following files will be attached: python.exe.manifest: This is a copy of the manifest resource that I put into the 2.6.1 python.exe file by hand for testing. The original manifest was the same but without the 2nd ... group. sample.py: the simple little sample I used to make the screenshots. Snap001,png: This is sample.py running with the original python.exe running on Vista. Notice the plain, flat, outdated and ugly win2k look and style of the notebook tabs and buttons. Snap002.png: The same sample running with a modified python.exe. Now it has textures, gradients, mouse-over effects and etc. and will match the look of other modern applications running on the machine that are using the standard themes. Added file: http://bugs.python.org/file12995/python.exe.manifest ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
Changes by Robin Dunn : Added file: http://bugs.python.org/file12996/sample.py ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
Changes by Robin Dunn : Added file: http://bugs.python.org/file12997/Snap001.png ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
Changes by Robin Dunn : Added file: http://bugs.python.org/file12998/Snap002.png ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
Robin Dunn added the comment: Sorry, no luck. I've tried before to ensure that all the DLLs and extension modules have the manifest file (in resource 2) and it makes no difference. I rebuilt wxWidgets and wxPython today with ISOLATION_AWARE_ENABLED defined to check if that would help, and reset the manifest resource in all the binaries, but it makes no difference. ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
Robin Dunn added the comment: Thanks for the code. I've verified your findings and I've also converted nested to an extension module and built it with distutils and was still able to make it correctly load the themed common controls when imported from Python, however I had to hack distutils a little bit to keep it working. In this case the code in msvc9compiler.py that runs mt.exe overwrites the manifest that is specified in the rc file with one that doesn't include the common controls assembly. I've still got to figure out what is the difference between this test and wxPython's build... It seems that none of the obvious things have any effect. ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
Robin Dunn added the comment: Update: I finally worked out what needed to be done for wxPython and while simply changing Python's manifest would have been immensely easier what I have does seem to work well so I thought I should give some info here for posterity. I went back and experimented again with creating an Activation Context in the C code that loads a proper manifest, and found that it seemed to work in some situations and not in others. I eventually narrowed it down to the fact that any UI object created from within a timer event handler would always use the processes' default context instead of any other activated context. (In this case that means that it would always use the manifest embedded in python.exe instead of any other manifest, programatically loaded or otherwise.) Since the main frame in wxPython's demo is loaded via a timer (when the splash screen times out) then this made it appear that all of my prior experiments had failed, when in fact some of them probably at least partially succeeded. After further experimentation I found that switching wxTimer to use a hidden window for catching and processing timer events, instead of using a TimerProc callback, solves the problem with the new activation context being ignored. So I guess we can call this a microsoft bug and move on. More details are in this thread: http://lists.wxwidgets.org/pipermail/wxpython-dev/2009-April/004199.html -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
