Installing Python 2.6 alpha1 on Windows XP
Hi Paul, thanks for you efforts, but up to now it still didn't work. I'm using Windows XP Professional (32 bit). I tried an install on two different machines with the same negative result. I proceeded like you suggested. - I installed for all users, - I disabled the register extensions When doing the same call to execute idle as you, I got the following: Traceback (most recent call last): File "c:\Python26\Lib\idlelib\idle.py", line 6, in <module> import PyShell File "c:\Python26\Lib\idlelib\PyShell.py", line 9, in <module> import socket File "c:\Python26\Lib\socket.py", line 46, in <module> import _socket ImportError: DLL load failed: <in German: system cannot find this file> I get a similar error message, when I do from turtle import * with ... import _tkinter Import Error. DLL load failed .... sys.path is exactly like yours. (So the DLLs directory is contained in sys.path) _tkinter.pyd and _socket.pyd are present in DLLs. I've installed Python 2.5 on both machines. On the first one I moreover deleted all entries concerning Python (2.5) from the PATH variable, with no positive effect. On the other machine I have also installed Python 3000 successfully, which even still doesn't have IDLE in it's Menu. Nevertheless there C:\Python30> python Lib\idlelib\idle.py brings up IDLE 3.0a1 (and I even can import and use a port of xturtle.py to Python 3000 there). I never experienced a similar Problem before when installing Python. Any ideas? Regards, Gregor
On 17/03/2008, Gregor Lingl <gregor.lingl@aon.at> wrote:
When doing the same call to execute idle as you, I got the following:
Traceback (most recent call last): File "c:\Python26\Lib\idlelib\idle.py", line 6, in <module> import PyShell File "c:\Python26\Lib\idlelib\PyShell.py", line 9, in <module> import socket File "c:\Python26\Lib\socket.py", line 46, in <module> import _socket ImportError: DLL load failed: <in German: system cannot find this file>
Can you try running C:\Python26\python.exe, and then at the interpreter prompt, execute: import sys print sys.path import socket and post the results? I expect you will get the same error about _socket not being loadable, but I'd like to check. Also can you try just "import _socket"? What is the size of _socket.pyd - mine is 44,032 bytes. Another thought - do you have any copies of msvcr90.dll on your PATH? I don't think it'll make a difference, but if you do can you try renaming them?
I never experienced a similar Problem before when installing Python.
Any ideas?
Not many :-( One final thought, what is the value of your PATH variable? Mine has no Python entries in it at all - that's normal, the Python installer doesn't set PATH. Sorry I can't be of more help, Paul.
Paul Moore schrieb:
On 17/03/2008, Gregor Lingl <gregor.lingl@aon.at> wrote:
When doing the same call to execute idle as you, I got the following:
Traceback (most recent call last): File "c:\Python26\Lib\idlelib\idle.py", line 6, in <module> import PyShell File "c:\Python26\Lib\idlelib\PyShell.py", line 9, in <module> import socket File "c:\Python26\Lib\socket.py", line 46, in <module> import _socket ImportError: DLL load failed: <in German: system cannot find this file>
Can you try running C:\Python26\python.exe, and then at the interpreter prompt, execute:
import sys print sys.path import socket
and post the results?
import sys print sys.path ['', 'C:\\Python26\\python26.zip', 'C:\\Python26\\DLLs', 'C:\\Python26\\lib', ] 'C:\\Python26\\lib\\plat-win', 'C:\\Python26\\lib\\lib-tk', 'C:\\Python26', 'C:\\Python26\\lib\\site-packages'] 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: Das System kann die angegebene Datei nicht finden. ;-) :-(
I expect you will get the same error about _socket not being loadable, but I'd like to check. Also can you try just "import _socket"?
import _socket Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: DLL load failed: Das System kann die angegebene Datei nicht finden.
What is the size of _socket.pyd - mine is 44,032 bytes.
The same
Another thought - do you have any copies of msvcr90.dll on your PATH? I don't think it'll make a difference, but if you do can you try renaming them?
No I don't! Only in c:\Python26, in c:\Python30 and on c:\Python30\DLLs. Strange that there are two copies of msvcr90.dll in Python30. So I'll copy this beast also to C:\Python26\DLLs, and ... it works! I can import socket and I even can start IDLE from the Python2.6 Menu Thanks for your advice. Do you have an idea if this is a 'bug' in the installer? Why the differences between 2.6 and 3000. Why two copies of that .dll in Python 30.0? I'm rather happy now :-) Have a nice evening. (Here in Vienna it's already 0:51 am.) All the best Gregor
I never experienced a similar Problem before when installing Python.
Any ideas?
Not many :-(
One final thought, what is the value of your PATH variable? Mine has no Python entries in it at all - that's normal, the Python installer doesn't set PATH.
Sorry I can't be of more help, Paul.
On 17/03/2008, Gregor Lingl <gregor.lingl@aon.at> wrote:
Another thought - do you have any copies of msvcr90.dll on your PATH? I don't think it'll make a difference, but if you do can you try renaming them?
No I don't! Only in c:\Python26, in c:\Python30 and on c:\Python30\DLLs. Strange that there are two copies of msvcr90.dll in Python30.
So I'll copy this beast also to C:\Python26\DLLs, and ... it works! I can import socket and I even can start IDLE from the Python2.6 Menu
That's odd. In theory, having msvcr90.dll in C:\Python26 should be sufficient, as once python.exe is loaded, its directory is added to the DLL search path. Maybe it's something to do with the "side by side manifest installation" stuff (or whatever it's called). Martin, can you comment? It looks like the 3.0 installer uses 2 copies of msvcr90.dll, where the 2.6 one doesn't. I would have thought that only one is necessary, but Gregor's experiments seem to demonstrate otherwise.
Thanks for your advice.
I'm not sure I did much more than get you to the point where you solved the problem for yourself, but I'm glad you've got things working :-)
Do you have an idea if this is a 'bug' in the installer?
I suspect it is - I've copied Martin for comment, but could you raise a bug in the tracker?
Why the differences between 2.6 and 3000.
I don't know, but that's what makes me think it's a bug (although I'm not entirely convinced that having 2 copies of the DLL, like 3.0 does, is the correct solution).
Why two copies of that .dll in Python 30.0?
I suspect it's a result of the msvcr90 "side by side" stuff. But beyond that, I don't know.
I'm rather happy now :-)
So am I. Glad things are working :-) Paul.
Paul Moore schrieb:
That's odd. In theory, having msvcr90.dll in C:\Python26 should be sufficient, as once python.exe is loaded, its directory is added to the DLL search path. Maybe it's something to do with the "side by side manifest installation" stuff (or whatever it's called).
Martin, can you comment? It looks like the 3.0 installer uses 2 copies of msvcr90.dll, where the 2.6 one doesn't. I would have thought that only one is necessary, but Gregor's experiments seem to demonstrate otherwise.
In practice it's not enough on XP and higher. Starting with XP, Windows supports side by side assemblies (SxS). SxS assemblies must be installed following a special convention. The MSDN web site contains some examples. It suc.. err it's fun :/ We are still having problems to integrate the MS Merge module into our MSI. Martin is working on the problem. In the mean time you can work around the problem by installing the MSVCRT 9.0 Redist. Christian
We are still having problems to integrate the MS Merge module into our MSI. Martin is working on the problem. In the mean time you can work around the problem by installing the MSVCRT 9.0 Redist.
While this is a work-around for the people trying to run the alpha releases, it effectively prevents them from doing useful tests in that area for the later releases. IIUC, there is NO way to uninstall the CRT redist (perhaps except for deleting the files from disk, and cleaning an unknown number of registry keys), so once you have run that on a machine, the machine becomes useless for determining whether the installer would work without it. As a consequence, regular testers won't report the problem anymore, as has been demonstrated with 2.6a1, it seems (which apparently doesn't work). Non-regular testers will have no clue what happened (which also was just demonstrated). Regards, Martin
That's odd. In theory, having msvcr90.dll in C:\Python26 should be sufficient, as once python.exe is loaded, its directory is added to the DLL search path. Maybe it's something to do with the "side by side manifest installation" stuff (or whatever it's called).
Yes, with VS 2008, the DLL search path becomes irrelevant (or so it seems).
Martin, can you comment? It looks like the 3.0 installer uses 2 copies of msvcr90.dll, where the 2.6 one doesn't. I would have thought that only one is necessary, but Gregor's experiments seem to demonstrate otherwise.
I haven't figured it out myself; it's a complete mess, and Microsoft is heavily wasting our time. It seems that you absolutely *must* have the manifest file in each directory that has a DLL which links with the CRT. Whether or not separate copies of the DLL are then also necessary, and whether or not that causes two copies to be loaded into the address space, I don't know. HELP!!!! To reproduce the problem, you probably have to test on a machine which doesn't have the CRT redistributable installed centrally (neither through VS 2008 installation, nor by running the standalone CRT installer, nor by having installed any other software that provides an SxS copy of the CRT). Regards, Martin
On 18/03/2008, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Martin, can you comment? It looks like the 3.0 installer uses 2 copies of msvcr90.dll, where the 2.6 one doesn't. I would have thought that only one is necessary, but Gregor's experiments seem to demonstrate otherwise.
I haven't figured it out myself; it's a complete mess, and Microsoft is heavily wasting our time.
It seems that you absolutely *must* have the manifest file in each directory that has a DLL which links with the CRT. Whether or not separate copies of the DLL are then also necessary, and whether or not that causes two copies to be loaded into the address space, I don't know. HELP!!!!
I'll see if I can wade through the documentation and offer any help.
To reproduce the problem, you probably have to test on a machine which doesn't have the CRT redistributable installed centrally (neither through VS 2008 installation, nor by running the standalone CRT installer, nor by having installed any other software that provides an SxS copy of the CRT).
That shouldn't be hard - I'll set up a Windows virtual machine with no additional software on it and can use that for testing. If you want me to try anything out, let me know and I can do so in a guaranteed clean environment. Paul.
That shouldn't be hard - I'll set up a Windows virtual machine with no additional software on it and can use that for testing. If you want me to try anything out, let me know and I can do so in a guaranteed clean environment.
I think I've a spare license of XP Home around somewhere. I'm going to install yet another XP in a VM, too. VMware supports snapshots and roll backs. I can try out multiple approaches and roll back the changes easily. Christian
That shouldn't be hard - I'll set up a Windows virtual machine with no additional software on it and can use that for testing. If you want me to try anything out, let me know and I can do so in a guaranteed clean environment.
That should be a reasonable setup. Try moving the manifest files and the copies of the CRT around, in the 2.6 installer which (reportedly) doesn't work; you should try to reproduce the error Gregor had first. Don't use the "all users" install, but the per-user one; for the all-users case, I need to add proper SxS support, installing into the assembly cache, which currently isn't implemented. Then, when it does work, try to figure out how to eliminate the extra copy of the CRT. Perhaps the manifest needs to be tweaked? Regards, Martin
Martin v. Löwis wrote:
That's odd. In theory, having msvcr90.dll in C:\Python26 should be sufficient, as once python.exe is loaded, its directory is added to the DLL search path. Maybe it's something to do with the "side by side manifest installation" stuff (or whatever it's called).
Yes, with VS 2008, the DLL search path becomes irrelevant (or so it seems).
Martin, can you comment? It looks like the 3.0 installer uses 2 copies of msvcr90.dll, where the 2.6 one doesn't. I would have thought that only one is necessary, but Gregor's experiments seem to demonstrate otherwise.
I haven't figured it out myself; it's a complete mess, and Microsoft is heavily wasting our time.
It seems that you absolutely *must* have the manifest file in each directory that has a DLL which links with the CRT. Whether or not separate copies of the DLL are then also necessary, and whether or not that causes two copies to be loaded into the address space, I don't know. HELP!!!!
To reproduce the problem, you probably have to test on a machine which doesn't have the CRT redistributable installed centrally (neither through VS 2008 installation, nor by running the standalone CRT installer, nor by having installed any other software that provides an SxS copy of the CRT).
FYI, here is a related bug report on this: http://bugs.python.org/issue2256 If you send me private email, I can test installs on that machine.
participants (5)
-
"Martin v. Löwis" -
Christian Heimes -
Gregor Lingl -
Jim Kleckner -
Paul Moore