| msg106745 - (view) |
Author: Marc-Andre Lemburg (lemburg) *  |
Date: 2010-05-29 23:30 |
| When installing Visual Studio 2008 SP1 on a Windows Vista x64 system, the installer registers the various registry keys under Software\Wow6432Node\Microsoft\VisualStudio\9.0\ rather than Software\Microsoft\VisualStudio\9.0\ This is due to some redirection MS is applying to registry names when running 32-bit apps (such as the VS2008 installer) on 64-bit Windows: http://support.microsoft.com/kb/896459 Since the tools in msvc9compiler.py rely on the registry to find the various dirs, batch files and tools, these operations fail. A simple solution is to just update the globals at the top of the file to: VS_BASE = r"Software\Wow6432Node\Microsoft\VisualStudio\%0.1f" WINSDK_BASE = r"Software\Wow6432Node\Microsoft\Microsoft SDKs\Windows" NET_BASE = r"Software\Wow6432Node\Microsoft\.NETFramework" but that would of course have to be done with some extra checks to not break these settings on other Windows systems. I'm not sure whether this is specific to Windows Vista or also occurs on Windows 7. |
|
|
| msg106750 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2010-05-30 07:25 |
| This shouldn't be necessary. If a 32-bit Python looks into the registry, it will get automatically redirected to Wow6432Node. If a 64-bit Python looks into the registry, it shouldn't have any interest in values stored in Wow6432Node. |
|
|
| msg106756 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-05-30 11:41 |
| Martin v. Löwis wrote: > > Martin v. Löwis <martin@v.loewis.de> added the comment: > > This shouldn't be necessary. If a 32-bit Python looks into the registry, it will get automatically redirected to Wow6432Node. If a 64-bit Python looks into the registry, it shouldn't have any interest in values stored in Wow6432Node. Perhaps I wasn't clear: The VS2008 installer as well as the most of VS tool chain appear to be 32-bit binaries and thus writes its keys and values into Software\Wow6432Node\Windows\. If you then run a 64-bit Python binary, it won't find the keys under the regular Software\Windows\ reg path. BTW: This was a fresh Vista and VS2008 installation. |
|
|
| msg107941 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-06-16 18:13 |
| Here's a patch fixing the problem. |
|
|
| msg107942 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-06-16 18:16 |
| If possible, the patch should go into Python 2.7 rc2, since without it, you can't build Python extensions on Windows x64 platforms. |
|
|
| msg108250 - (view) |
Author: Tarek Ziadé (tarek) * |
Date: 2010-06-20 21:40 |
| The patch looks good but I am not comfortable with this change until it's tested under other windows/VC flavors. I'll leave it up to Benjamin to decide whether it goes in rc2 |
|
|
| msg108257 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-06-21 08:43 |
| Tarek Ziadé wrote: > > Tarek Ziadé <ziade.tarek@gmail.com> added the comment: > > The patch looks good but I am not comfortable with this change until it's tested under other windows/VC flavors. The patch is really trivial, but I'll test it on a Windows x86 installation as well today. Would be great if we could get someone else test it on their Windows x64 system. It's strange that noone has noticed this problem while Python 2.6 was out. I know that Martin uses a cross-compiling setup to create the 64-bit installers, so he wouldn't have noticed, but others should have seen similar problems, trying to compile extensions on Windows x64. I guess most people still use the 32-bit Python installers on Windows x64 systems. |
|
|
| msg108258 - (view) |
Author: Tarek Ziadé (tarek) * |
Date: 2010-06-21 08:44 |
| I am adding srid in the nosy list. I believe he can test those platforms as well if he's around |
|
|
| msg108260 - (view) |
Author: Konstantin Zemlyak (zart) |
Date: 2010-06-21 11:12 |
| Win2003 x64, VS2008, vanilla python 2.7rc1 amd64 from python.org. Building python packages with C extensions works fine. Tested on simplejson, jinja2 (with enabled speedups) and PIL. |
|
|
| msg108261 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-06-21 11:39 |
| Konstantin Zemlyak wrote: > > Konstantin Zemlyak <zart@zartsoft.ru> added the comment: > > Win2003 x64, VS2008, vanilla python 2.7rc1 amd64 from python.org. > Building python packages with C extensions works fine. Tested on simplejson, jinja2 (with enabled speedups) and PIL. I assume that you built without the patch applied. Does it also work with the patch ? This is the relevant section from the KB article: """ When you install a new program or when you run a program on a Windows x64 Edition computer, registry calls made by 64-bit programs access the HKEY_LOCAL_MACHINE\Software registry sub key without redirection. WOW64 intercepts registry calls to HKEY_LOCAL_MACHINE\Software that are made by 32-bit programs, and then redirects them to the HKEY_LOCAL_MACHINE\Software\WOW6432node sub key. """ Since VS2008 is a 32-bit application, the registry keys are written to the HKEY_LOCAL_MACHINE\Software\WOW6432node branch. 64-bit applications such as Python AMD64 don't see this indirection, so they have to explicitly look in that branch to find VS2008 settings. I checked the registry on the machine and indeed the VS2008 keys are only available under the HKEY_LOCAL_MACHINE\Software\WOW6432node branch. |
|
|
| msg108263 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-06-21 11:59 |
| I checked this again using Python 2.7rc1 AMD64 on Windows Vista x64 using VS2008 and get the same error: error: Unable to find vcvarsall.bat Here's an updated patch for Python 2.7rc1. |
|
|
| msg108264 - (view) |
Author: Konstantin Zemlyak (zart) |
Date: 2010-06-21 12:11 |
| 64-bit Windows, 64-bit cmd.exe, 64-bit python, not patched:: D:\>"c:\Program Files\Python27\python.exe" Python 2.7rc1 (r27rc1:81787, Jun 6 2010, 20:03:36) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import distutils.msvc9compiler >>> distutils.msvc9compiler.get_build_version() 9.0 >>> distutils.msvc9compiler.find_vcvarsall(9.0) 'c:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat' >>> How did you test? Maybe it's some difference in setup. |
|
|
| msg108266 - (view) |
Author: Konstantin Zemlyak (zart) |
Date: 2010-06-21 12:31 |
| Tried msvc9compiler-py27.patch. find_vcvarsall() still works with the same result, while distutils.msvc9compiler.VS_BASE has been changed. :: >>> distutils.msvc9compiler.find_vcvarsall(9.0) u'c:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat' >>> distutils.msvc9compiler.VS_BASE 'Software\\Wow6432Node\\Microsoft\\VisualStudio\\%0.1f' Checked registry, 9.0 is only under Wow6432Node. |
|
|
| msg108267 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-06-21 12:36 |
| Konstantin Zemlyak wrote: > > Konstantin Zemlyak <zart@zartsoft.ru> added the comment: > > 64-bit Windows, 64-bit cmd.exe, 64-bit python, not patched:: > > D:\>"c:\Program Files\Python27\python.exe" > Python 2.7rc1 (r27rc1:81787, Jun 6 2010, 20:03:36) [MSC v.1500 64 bit (AMD64)] > on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> import distutils.msvc9compiler > >>> distutils.msvc9compiler.get_build_version() > 9.0 > >>> distutils.msvc9compiler.find_vcvarsall(9.0) > 'c:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat' > >>> > > How did you test? Maybe it's some difference in setup. I'm running the build process using a batch file which is invoked through a remote shell. Trying the same build from within a cmd.exe started locally on the machine does not cause the error messages, so I guess this does indeed have to do with the way the Python interpreter is invoked. Further inspection shows that in case the registry key is not found, the find_vcvarsall() function uses the OS environment to find the installation. With the local cmd.exe, the OS environment does indeed have the entry that points the function to the installation: VS90COMNTOOLS Using the remote shell, those VS2008 env vars are not set and so the build fails. Could you check the registry keys on your installation ? I put these extra log lines into the find_vcvarsall() function to see what the registry has stored: vsbase = VS_BASE % version try: productdir = Reg.get_value(r"%s\Setup\VC" % vsbase, "productdir") except KeyError: productdir = None log.info('VS2008 product dir: %s - %s' % (productdir, vsbase)) # trying Express edition if productdir is None: vsbase = VSEXPRESS_BASE % version try: productdir = Reg.get_value(r"%s\Setup\VC" % vsbase, "productdir") except KeyError: productdir = None log.debug("Unable to find productdir in registry") log.info('VS2008 product dir: %s - %s' % (productdir, vsbase)) The output is: VS2008 product dir: None - Software\Microsoft\VisualStudio\9.0 VS2008 product dir: None - Software\Microsoft\VCExpress\9.0 |
|
|
| msg108268 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-06-21 12:38 |
| Konstantin Zemlyak wrote: > > Konstantin Zemlyak <zart@zartsoft.ru> added the comment: > > Tried msvc9compiler-py27.patch. find_vcvarsall() still works with the same result, while distutils.msvc9compiler.VS_BASE has been changed. > > :: > >>> distutils.msvc9compiler.find_vcvarsall(9.0) > u'c:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\vcvarsall.bat' > >>> distutils.msvc9compiler.VS_BASE > 'Software\\Wow6432Node\\Microsoft\\VisualStudio\\%0.1f' > > Checked registry, 9.0 is only under Wow6432Node. Thanks for confirming that. So at least my setup is not special and the keys do indeed have to be updated fir Win64 platforms. |
|
|
| msg108269 - (view) |
Author: Konstantin Zemlyak (zart) |
Date: 2010-06-21 12:55 |
| > Using the remote shell, those VS2008 env vars are not set and > so the build fails. Seems it doesn't load user profile. > The output is: > > VS2008 product dir: None - Software\Microsoft\VisualStudio\9.0 > VS2008 product dir: None - Software\Microsoft\VCExpress\9.0 Same for me. Your patch fixes registry lookup. |
|
|
| msg108276 - (view) |
Author: Benjamin Peterson (benjamin.peterson) * |
Date: 2010-06-21 15:28 |
| Applied patch in r82130. Thanks! |
|
|
| msg108283 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-06-21 16:13 |
| Benjamin Peterson wrote: > > Benjamin Peterson <benjamin@python.org> added the comment: > > Applied patch in r82130. Thanks! Thanks, Benjamin. |
|
|