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

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

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)

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:

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

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 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.