Repository navigation
"for me" installer problem on x64 Vista #48268
Description
| BPO | 4018 |
|---|---|
| Nosy | @loewis, @warsaw, @tiran |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/loewis'
closed_at = <Date 2008-10-13.11:34:21.739>
created_at = <Date 2008-10-02.16:06:10.859>
labels = ['type-bug', 'OS-windows', 'release-blocker']
title = '"for me" installer problem on x64 Vista'
updated_at = <Date 2008-10-18.14:25:00.381>
user = 'https://bugs.python.org/jpe'bugs.python.org fields:
activity = <Date 2008-10-18.14:25:00.381>
actor = 'loewis'
assignee = 'loewis'
closed = True
closed_date = <Date 2008-10-13.11:34:21.739>
closer = 'loewis'
components = ['Windows']
creation = <Date 2008-10-02.16:06:10.859>
creator = 'jpe'
dependencies = []
files = ['11711']
hgrepos = []
issue_num = 4018
keywords = ['patch', 'needs review']
message_count = 18.0
messages = ['74168', '74169', '74172', '74175', '74193', '74196', '74201', '74208', '74215', '74216', '74220', '74249', '74250', '74373', '74379', '74681', '74951', '74952']
nosy_count = 8.0
nosy_names = ['loewis', 'barry', 'jpe', 'christian.heimes', 'psycoman', 'rpetrov', 'slee', 'armandorowe']
pr_nums = []
priority = 'release blocker'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue4018'
versions = ['Python 2.6', 'Python 3.0']
Activity
jpe commentedon Oct 2, 2008
After installing the 32 bit .msi or the 64 bit .msi "for me" on a fairly
clean Vista x64 machine, the socket module won't import because of a
side-by-side configuration error. The output below is from the 32 bit
build.
Microsoft Windows [Version 6.0.6000]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Users\maint>\python26\python Python 2.6 (r26:66721, Oct 2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> import socket Traceback (most recent call last): File "<stdin>", line 1, in <module> File "C:\python26\lib\socket.py", line 46, in <module> import _socket ImportError: DLL load failed: The application has failed to start because its si de-by-side configuration is incorrect. Please see the application event log for more detail. >>>The event log entry for this is:
Activation context generation failed for
"C:\python26\DLLs\_socket.pyd".Error in manifest or policy file
"C:\python26\DLLs\Microsoft.VC90.CRT.MANIFEST" on line 12. The value
"../msvcr90.dll" of attribute "name" in element
"urn:schemas-microsoft-com:asm.v1^file" is invalid.
Changing ../msvcr90.dll to ..\msvcr90.dll does not fix the problem
Importing socket does work when the msi is installed for everyone.
tiran commentedon Oct 2, 2008
Could you try it again with "..\\msvcr90.dll", please?
jpe commentedon Oct 2, 2008
Neither "..\\msvcr90.dll" or a full path work (with \ or \\) seem to work.
tiran commentedon Oct 2, 2008
I don't have a Vista box at my disposal. Martin might be able to help you.
Barry:
I've marked this bug as blocker because it makes Vista installations
useless. It's not a blocker for the upcoming beta but it should be fixed
before the next rc. It's a rather nasty issue with side-by-side
assemblies. It can only be debugged on a Vista machine *WITHOUT* any
development tools like Visual Studio or 3rd party programs shipped with
msvcrt90 assembly.
loewis commentedon Oct 2, 2008
I had noticed the problem myself, and I don't know any solution to it.
It's still part of the aftermath of switching to VS 2008, maybe we
should have stayed with VS 2003 :-(
Out of curiosity: Is this Vista SP1? If so, can somebody try Vista RTM?
I recall that it used to work, but I don't have any Vista RTM
installation anymore.
In short, the problem is that Vista now complains about the .. in the
name attribute of the manifest; XP considers the manifest file fine.
A work-around is to place another copy of msvcr90.dll into the DLLs
order, and adjusting the manifest to point to this copy. I rejected this
solution, as it causes two copies of the CRT to be loaded (as can be
seen in sysinternals process explorer). Loading two copies of the CRT
itself caused problems in the past (e.g. when FILE* is passed across DLL
boundaries).
As a consequence, I propose that the "for me" installation just isn't
supported on Vista; it should be easy to adjust the UI accordingly.
Vista users should invoke the "for all installation" (and I should
change the installer back to invoking UAC).
In any case, I don't think this should block the release, given that no
real solution seems possible.
jpe commentedon Oct 2, 2008
I think one of the tested machines is Vista RTM, though it's been
updated. I also tried of Vista x32 SP1 and it fails there.
If non-admin installs can't be made to work, I agree that the "for me"
option be dropped and the installer changed to invoke UAC. I looked for
a solution to this, but so far can't find any -- and this would also
mean that .pyd files in site-packages and elsewhere would need .manifest
files that contain the path to where msvcr90.dll is located. I think
requiring an admin install might cause problems for py2exe though.
This is rather important because it means that python is unusable using
the default installation options and I suspect that many users won't
know how to install for everyone.
I'd still like to see the need to depend on a C runtime dll dropped at
some point in the future, but I know that it's not an easy thing to do.
loewis commentedon Oct 2, 2008
I don't think this could even work: apparently, Vista disallows putting
a path into the name field. So extension modules will have to ship with
their own copy of the CRT (or link statically).
jpe commentedon Oct 2, 2008
I agree that this is the case. The closest thing I found to
documentation of this is
http://msdn.microsoft.com/en-us/library/ms235291.aspx under Deploying
Visual C++ library DLLs as private assemblies. It specifies that the
assembly be copied twice, once into the folder with the .exe and again
into the folder with the .dll.
I think the best option is to always install for everyone as
administrator on Vista.
rpetrov commentedon Oct 2, 2008
May be call of SetDllDirectory with argument path to python executable
before to load a python module may help.
armandorowe commentedon Oct 2, 2008
See bpo-4022 for a similar problem in WIndows XP professional,
installed for all users.
loewis commentedon Oct 3, 2008
I'm skeptical. According to the documentation, "The directory from which
the application loaded." is already in the search path, and even before
lpPathName. Can you try it out and propose a patch if it works?
slee commentedon Oct 3, 2008
I spotted the problem on Vista Home Premium SP1 32bit
As John indicates the problem with the 'all users' install is that it
requires elevation to run as admin even if logged in as an
administrator. That is rather non obvious (John suggests running cmd.exe
as administrator which works fine). As most people doing it will be
developers and have own machine it is not a big issue (assuming use
py2exe, eggs etc. is used for end user setup ;-)) Oh I wonder if the
same problem exists there?
I ran into SxS problems on XP when building Python 2.5.? from source for
use in Mozilla XULRunner and needed to use VC8 Express for both (so same
CRT). I moved on so never fully resolved it apart from dropping copies
of the CRT in various system folders.
slee commentedon Oct 3, 2008
The mozilla bug is https://bugzilla.mozilla.org/show_bug.cgi?id=371359
but looking at it now, especially comment 4, it's not much help.
loewis commentedon Oct 6, 2008
Here is a patch that fixes the problem as proposed. An installer built
with that patch is available from
http://www.dcl.hpi.uni-potsdam.de/home/loewis/u/python-3.0.14158.msi
slee commentedon Oct 6, 2008
Works for me on Vista, Not tried on XP.
Seems a reasonable temporary compromise though we are now stopping all
possibility of an 'all' install but as noted there is probably little
need for it when application installers are created.
loewis commentedon Oct 13, 2008
Thanks for the confirmation. Committed as r66881, r66882, and r66883.
psycoman commentedon Oct 18, 2008
existis a 2.6 fix or a build with fix?
loewis commentedon Oct 18, 2008
No, this will be fixed in 2.6.1.