Win64 AMD64 (aka x64) binaries available64
I have now produces a snapshot of a Win64 build for AMD64 processors (also known as EM64T or x64); this is different from IA-64 (which is also known as Itanium)... Anyway, the binaries are http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13199.amd64.msi This is from today's trunk. If you have general remarks/discussion, please post to python-dev. If you have specific bug reports, file them on SF. Bug fixes are particularly welcome. Known issues: - _ssl.pyd is not build (I get linker errors) - some of the tests fail (in some cases, due to bugs in the test suite) If you want to build extensions for this build using distutils, you need to 1. install the platform SDK (2003 SP1 should work) 2. open an AMD64 retail shell 3. run the included distutils It might be possible to drop 2) some day, but finding the SDK from the registry is really tricky. Regards, Martin
[Martin v. Loewis wrote]
If you want to build extensions for this build using distutils, you need to ... 2. open an AMD64 retail shell ...
It might be possible to drop 2) some day, but finding the SDK from the registry is really tricky.
Look for: def find_platform_sdk_dir() here: http://cvs.sourceforge.net/viewcvs.py/pywin32/pywin32/setup.py?view=markup That is the best code I know for doing that. Trent -- Trent Mick TrentM@ActiveState.com
Trent Mick wrote:
Look for: def find_platform_sdk_dir() here: http://cvs.sourceforge.net/viewcvs.py/pywin32/pywin32/setup.py?view=markup
That is the best code I know for doing that.
Right; I was planning something similar (although I would probably hard-code the 2003 SP1 registry key - it is not at all certain that future SDK releases will use the same registry scheme, and Microsoft has tricked users often enough in thinking they understood the scheme, just to change it with the next release entirely). Regards, Martin
Martin v. Löwis wrote:
I have now produces a snapshot of a Win64 build for AMD64 processors (also known as EM64T or x64); this is different from IA-64 (which is also known as Itanium)...
Anyway, the binaries are
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13199.amd64.msi
This is from today's trunk. If you have general remarks/discussion, please post to python-dev. If you have specific bug reports, file them on SF. Bug fixes are particularly welcome.
Is this no longer available? BTW: When I build Python for ReleaseAMD64 myself, the exe crashes at the first Py_BuildValue call. Thomas
Thomas Heller wrote:
Is this no longer available?
Sorry, I just deleted that. I now replaced it with python-2.5.13231.amd64.msi
BTW: When I build Python for ReleaseAMD64 myself, the exe crashes at the first Py_BuildValue call.
That doesn't happen for me... can you find out why it crashes? (and what is the buildvalue call it crashes on)? Regards, Martin
Martin v. Löwis wrote:
Thomas Heller wrote:
Is this no longer available?
Sorry, I just deleted that. I now replaced it with python-2.5.13231.amd64.msi
Thanks, I'll try that.
BTW: When I build Python for ReleaseAMD64 myself, the exe crashes at the first Py_BuildValue call.
That doesn't happen for me... can you find out why it crashes? (and what is the buildvalue call it crashes on)?
In sys_getwindowsversion: return Py_BuildValue("HHHHs", ver.dwMajorVersion, ver.dwMinorVersion, ver.dwBuildNumber, ver.dwPlatformId, ver.szCSDVersion); The crash disappears if I change the first parameter in the Py_BuildValue call to "LLLLs". No idea why. With this change, I can start the exe without a crash, but sys.versioninfo starts with (IIRC) (2, 0, 5,...). Thomas
Thomas Heller wrote:
In sys_getwindowsversion:
return Py_BuildValue("HHHHs", ver.dwMajorVersion, ver.dwMinorVersion, ver.dwBuildNumber, ver.dwPlatformId, ver.szCSDVersion);
The crash disappears if I change the first parameter in the Py_BuildValue call to "LLLLs". No idea why. With this change, I can start the exe without a crash, but sys.versioninfo starts with (IIRC) (2, 0, 5,...).
Very strange. What is your compiler version (first line of cl /?)? 'H' isn't exactly right, since these are DWORDs, so they are unsigned longs, not unsigned ints (so 'k' should be right), however, the actually bug apparently is elsewhere - something like memory corruption. Can you find out what the value of szCSDVersion is (e.g. by putting a printf right before that)? Regards, Martin
Martin v. Löwis wrote:
Thomas Heller wrote:
In sys_getwindowsversion:
return Py_BuildValue("HHHHs", ver.dwMajorVersion, ver.dwMinorVersion, ver.dwBuildNumber, ver.dwPlatformId, ver.szCSDVersion);
The crash disappears if I change the first parameter in the Py_BuildValue call to "LLLLs". No idea why. With this change, I can start the exe without a crash, but sys.versioninfo starts with (IIRC) (2, 0, 5,...).
Very strange. What is your compiler version (first line of cl /?)?
'H' isn't exactly right, since these are DWORDs, so they are unsigned longs, not unsigned ints (so 'k' should be right), however, the actually bug apparently is elsewhere - something like memory corruption. Can you find out what the value of szCSDVersion is (e.g. by putting a printf right before that)?
I would prefer to examine this further when I'm able to compile Python on the AMD64 machine. Currently I'm not, because the VSExtCompiler Plugin cannot determine the SDK path from the registry. This is vsextcomp 0.6. I have installed the 2003 Server SP1 SDK. I tried installing the Feb 2003 SDK (since that did work on a 32-bit machine), but this won't install on XP-64. Thomas
Thomas Heller wrote:
return Py_BuildValue("HHHHs", ver.dwMajorVersion, ver.dwMinorVersion, ver.dwBuildNumber, ver.dwPlatformId, ver.szCSDVersion);
The crash disappears if I change the first parameter in the Py_BuildValue call to "LLLLs". No idea why. With this change, I can start the exe without a crash, but sys.versioninfo starts with (IIRC) (2, 0, 5,...).
Very strange. What is your compiler version (first line of cl /?)?
I have looked into this. In the latest SDK (2003 SP1), Microsoft has changed the include structure; there are no separate amd64 subdirectories anymore. Then, cl.exe was picking up the wrong stdarg.h (the one of VS 2003), which would not work for AMD64. I have corrected that in vsextcomp, but I will need to check a few more things before releasing it. Regards, Martin
Martin v. Löwis wrote:
Thomas Heller wrote:
return Py_BuildValue("HHHHs", ver.dwMajorVersion, ver.dwMinorVersion, ver.dwBuildNumber, ver.dwPlatformId, ver.szCSDVersion);
The crash disappears if I change the first parameter in the Py_BuildValue call to "LLLLs". No idea why. With this change, I can start the exe without a crash, but sys.versioninfo starts with (IIRC) (2, 0, 5,...).
Very strange. What is your compiler version (first line of cl /?)?
I have looked into this. In the latest SDK (2003 SP1), Microsoft has changed the include structure; there are no separate amd64 subdirectories anymore. Then, cl.exe was picking up the wrong stdarg.h (the one of VS 2003), which would not work for AMD64.
I have corrected that in vsextcomp, but I will need to check a few more things before releasing it.
I've upgraded to vsextcomp0.8. On XP (32-bit), I can compile python25.dll and python.exe for AMD64 now, after adding bufferoverflowU.lib to the linker options. And the exe even works on XP-64 ;-) When trying to build on XP64, I get errors like these (if it helps, I can upload the complete buildlogs somewhere): ------ Rebuild All started: Project: make_buildinfo, Configuration: Release Win32 ------ Deleting intermediate files and output files for project 'make_buildinfo', configuration 'Release|Win32'. Compiling... ------ CL.EXE Wrapper for VSExtCompiler Plugin ------ Error : Could not create new temporary options response file------ CL.EXE Wrapper for VSExtCompiler Plugin ------ ------ CL.EXE Wrapper for VSExtCompiler Plugin ------ (lots of these lines removed) ------ CL.EXE Wrapper for VSExtCompiler Plugin ------ Linking... ------ LINK.EXE Wrapper for VSExtCompiler Plugin ------ Error : Could not create new temporary options response file------ LINK.EXE Wrapper for VSExtCompiler Plugin ------ ------ LINK.EXE Wrapper for VSExtCompiler Plugin ------ (lots of these lines removed) ------ LINK.EXE Wrapper for VSExtCompiler Plugin ------ Build log was saved at "file://c:\devel\trunk\PCbuild\x86-temp-release\make_buildinfo\BuildLog.htm" make_buildinfo - 0 error(s), 0 warning(s) ------ Rebuild All started: Project: make_versioninfo, Configuration: Release Win32 ------ Deleting intermediate files and output files for project 'make_versioninfo', configuration 'Release|Win32'. Compiling... ------ CL.EXE Wrapper for VSExtCompiler Plugin ------ Error : Could not create new temporary options response file------ CL.EXE Wrapper for VSExtCompiler Plugin ------ ------ CL.EXE Wrapper for VSExtCompiler Plugin ------ (lots of these lines removed) ------ CL.EXE Wrapper for VSExtCompiler Plugin ------ Linking... ------ LINK.EXE Wrapper for VSExtCompiler Plugin ------ Error : Could not create new temporary options response file------ LINK.EXE Wrapper for VSExtCompiler Plugin ------ ------ LINK.EXE Wrapper for VSExtCompiler Plugin ------ (lots of these lines removed) ------ LINK.EXE Wrapper for VSExtCompiler Plugin ------ Performing Custom Build Step '.\make_versioninfo.exe' is not recognized as an internal or external command, operable program or batch file. Project : error PRJ0019: A tool returned an error code from "Performing Custom Build Step" Build log was saved at "file://c:\devel\trunk\PCbuild\x86-temp-release\make_versioninfo\BuildLog.htm" make_versioninfo - 1 error(s), 0 warning(s)
Thomas Heller wrote:
On XP (32-bit), I can compile python25.dll and python.exe for AMD64 now, after adding bufferoverflowU.lib to the linker options.
On what project? There should be /GS- options on all projects that need it, which, in turn, should result in bufferoverflowU.lib not being needed. Or I forgot to check that change in... Will do Monday.
Error : Could not create new temporary options response file
I've never seen these. I will have to study the source again, and find out how that could happen. Do you have spaces in the directory leading to the working copy? Regards, Martin
Martin v. Löwis wrote:
Thomas Heller wrote:
On XP (32-bit), I can compile python25.dll and python.exe for AMD64 now, after adding bufferoverflowU.lib to the linker options.
On what project? There should be /GS- options on all projects that need it, which, in turn, should result in bufferoverflowU.lib not being needed.
Or I forgot to check that change in... Will do Monday.
Ok, /GS- helps. No need to hurry - I would commit that myself but I only have readonly sandboxes on these installations, no putty, and so on.
Error : Could not create new temporary options response file
I've never seen these. I will have to study the source again, and find out how that could happen.
Do you have spaces in the directory leading to the working copy?
No. But your guess is somewhat correct: If I move the sandbox to a path *with* spaces in it, this problem goes away ;-). On the 64-bit box. Now I have to learn how to debug on win64. Thanks, Thomas
Thomas Heller wrote:
Martin v. Löwis wrote:
Thomas Heller wrote:
On XP (32-bit), I can compile python25.dll and python.exe for AMD64 now, after adding bufferoverflowU.lib to the linker options. On what project? There should be /GS- options on all projects that need it, which, in turn, should result in bufferoverflowU.lib not being needed.
Or I forgot to check that change in... Will do Monday.
Ok, /GS- helps. No need to hurry - I would commit that myself but I only have readonly sandboxes on these installations, no putty, and so on.
Error : Could not create new temporary options response file I've never seen these. I will have to study the source again, and find out how that could happen.
Do you have spaces in the directory leading to the working copy?
No.
But your guess is somewhat correct: If I move the sandbox to a path *with* spaces in it, this problem goes away ;-). On the 64-bit box.
I forgot to mention that there are a lot of warnings about conversion betweem Py_ssize_t to int - if you want me to fix the obvious ones I'll offer to correct some of them from time to time and commit the changes. I wonder why gcc doesn't warn about those. Thomas
Thomas Heller wrote:
I forgot to mention that there are a lot of warnings about conversion betweem Py_ssize_t to int - if you want me to fix the obvious ones I'll offer to correct some of them from time to time and commit the changes.
Right - they have been there ever since I started (in fact, I started this entire project *because* of these warnings). You can get them on x86, too, if you enable /Wp64. Please feel free to fix any of them that you feel comfortable about.
I wonder why gcc doesn't warn about those.
It just doesn't implement truncation warnings between variables of differently-sized integer types. This (typically) isn't undefined behaviour: the C standard mandates very well what should happen for these truncations. Warning about any and all truncations would lead to incredible noise. /Wp64 *only* works because they restrict themselves to int64->int32 warnings (essentially). Regards, Martin
On 4/21/06, "Martin v. Löwis"
Thomas Heller wrote:
I forgot to mention that there are a lot of warnings about conversion betweem Py_ssize_t to int - if you want me to fix the obvious ones I'll offer to correct some of them from time to time and commit the changes.
Right - they have been there ever since I started (in fact, I started this entire project *because* of these warnings). You can get them on x86, too, if you enable /Wp64.
In case it wasn't clear, the /Wp64 flag is available in icc (Intel's C compiler). n
Neal Norwitz wrote:
Right - they have been there ever since I started (in fact, I started this entire project *because* of these warnings). You can get them on x86, too, if you enable /Wp64.
In case it wasn't clear, the /Wp64 flag is available in icc (Intel's C compiler).
It still isn't clear :-) The flags is also available in msvc: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html... There is even a checkbox for it in the project settings. Regards, Martin
On 4/21/06, "Martin v. Löwis"
Neal Norwitz wrote:
Right - they have been there ever since I started (in fact, I started this entire project *because* of these warnings). You can get them on x86, too, if you enable /Wp64.
In case it wasn't clear, the /Wp64 flag is available in icc (Intel's C compiler).
It still isn't clear :-) The flags is also available in msvc:
Glad to see there's still some humour left on py-dev. I didn't say /Wp64 was *only* available in icc. For anyone who thinks I implied msvc, I've got a bridge for sale, just let me know. :-) Cheers, n
On Saturday 22 April 2006 15:27, Neal Norwitz wrote:
In case it wasn't clear, the /Wp64 flag is available in icc (Intel's C compiler).
Is it worth turning this on for the icc ubuntu buildbot? Anyone got ideas on the best way to do this? Should I just set CFLAGS="-Wp64" before running the buildbot on the box (it's sitting 2 feet behind my head in the rack in my study(*)) Anthony (*) Yes, I have an almost-rack of machines in my house. And yes, this scares me.
Anthony Baxter wrote:
On Saturday 22 April 2006 15:27, Neal Norwitz wrote:
In case it wasn't clear, the /Wp64 flag is available in icc (Intel's C compiler).
Is it worth turning this on for the icc ubuntu buildbot? Anyone got ideas on the best way to do this? Should I just set CFLAGS="-Wp64" before running the buildbot on the box (it's sitting 2 feet behind my head in the rack in my study(*))
Anthony
(*) Yes, I have an almost-rack of machines in my house. And yes, this scares me.
You should be scared what people are doing with your machines :-) From http://www.python.org/dev/buildbot/trunk/x86%20Ubuntu%20dapper%20%28icc%29%2... 'OPT': '-Wp64 -g -O3' icc -pthread -c -fno-strict-aliasing -Wp64 -g -O3 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c Regards, Martin
participants (5)
-
"Martin v. Löwis" -
Anthony Baxter -
Neal Norwitz -
Thomas Heller -
Trent Mick