I believe the current pyport.h for windows x64 has some problems. It
does not work for compilers which are not MS ones, because building
against the official binary (python 2.6) relies on features which are
not enabled unless MS_WIN64 is defined, and the later is not defined if
an extension is not built with MS compiler.

As a simple example:

#include <Python.h>

int main()
{
    printf("sizeof(Py_intptr_t) = %d\n", sizeof(Py_intptr_t));
    return 0;
}

If you build this with MS compiler, you get the expected
sizeof(Py_intptr_t) = 8, but with gcc, you get 4. Now, if I build the
test like:

gcc -I C:\Python26\include -DMS_WIN64 main.c

Then I got 8 as well.

I believe the attached patch should fix the problem (I have not tested
it, since building python on amd64).

Is there any change to see this integrated soon ? The patch is only a
couple of lines long,

thanks

Can you please provide some setup instructions for mingw-w64? What URLs 
should I install in what order, so that I can compile Python?

I think compiling python itself with it would be quite difficult - I
have never attempted it. My 'scenario' is building extensions against
the official python for amd64 on windows.

The quickest way to test the patch would be as follows:
 - take a native toolchain (by native, I mean runs on and target 64 bits
windows subsystem - I have not tested cross compilation, or even using
32 bits toolchain on WoW). The one from equations.com is recent and runs
well:

http://www.equation.com/servlet/equation.cmd?call=fortran

 - builds a hello-world like python extension from the command line:

http://projects.scipy.org/numpy/wiki/MicrosoftToolchainSupport (I am
sorry, the wiki page is bit messy, I will clean it up).

Since we use our own distutils extensions in numpy, I don't know how
much is needed for support at the stdlib distutils level. If that's
something which sounds interesting to python itself, I am willing to add
support in python proper for mingw-w64.

Lowering the priority. It's too difficult to setup the environment to be
able to reproduce the issue being fixed.

The toolchain is difficult to build, but the patch is easy to review, it
just moves the MS_WIN64 outside the MS compiler specific part. If it
does not break the MS toolchain (the one used to build the official
python), I don't see the problem.

I can make the toolchain available to you as a tarball, though, so that
you can easily test from a windows command shell without having to
install anything.

Ok, it looks like following gcc 4.4.0 release, there is an installer for
the whole toolchain:

http://www.equation.com/servlet/equation.cmd?call=fortran

This installs gcc (C+Fortran+C++ compilers, the download is ~ 40 Mb),
and it can be used from the command line as conventional mingw32.
Hopefully, this should make the patch much easier to test.

> The toolchain is difficult to build, but the patch is easy to review, it
> just moves the MS_WIN64 outside the MS compiler specific part. If it
> does not break the MS toolchain (the one used to build the official
> python), I don't see the problem.

As a principle, I always try to reproduce a problem when reviewing a
patch. In many cases, doing so reveals insights into the actual problem,
and leads to a different patch.

That the patch is "harmless" is not a convincing reason to apply it.

> I can make the toolchain available to you as a tarball, though, so that
> you can easily test from a windows command shell without having to
> install anything.

That would be nice.

I have now tried reproducing the problem, and still failed to. I downloaded, from http://sourceforge.net/projects/mingw-w64/files/, the distribution mingw-w32-bin_i686-mingw_20100123_sezero.zip.

With this, I get

c:\cygwin\mingw64\bin\gcc.exe -mno-cygwin -shared -s build\temp.win-amd64-2.6\Release\w64test.o build\temp.win-amd64-2.6\Release\w64test.def -LC:\Python26\libs -LC:\Python26\PCbuild\amd64 -lpython26 -lmsvcr90 -o build\lib.win-amd64-2.6\w64test.pyd
c:/cygwin/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.4.3/../../../../x86_64-w64
-mingw32/bin/ld.exe: cannot find -lmsvcr90
collect2: ld returned 1 exit status 

How am I supposed to link with this toolchain? If linking with -lmscvr90 is incorrect, what should I use instead? If it is correct, where do I get the proper import library from?

Hi Martin,

It was nice meeting you at Pycon.

I finally took the time to set up a windows 64 bits environment, and here are the exact steps I needed to do to reproduce the issue, and fix it by hand:

  - Start fresh from windows 7 64 bits
  - clone python hg repository, and checkout the 2.6 branch (path referred as $PYTHON_ROOT from now on).
  - build python with VS 2008 pro, 64 bits (release mode)
  - install mingw-w64. I used this exact version: mingw-w64-1.0-bin_i686-mingw_20110328.zip (release 1.0, targetting win64 but running in 32 bits native mode), and unzipped it in C:¥
  - I compiled a trivial C extension in foo.c as follows:

C:\mingw-w64\bin\x86_64-w64-mingw32-gcc.exe foo.c -I $PYTHON_ROOT\Include -I $PYTHON_ROOT\PC -shared -o foo.pyd  $PYTHON_ROOT\PCbuild\amd64\python26.lib -DMS_WIN64

The patch removes the need for defining MS_WIN64. I don't know exactly the policies for which branch this could be applied - anything below 2.6 does not make much sense since most win64 users use 2.6 at least. Ideally, it could be backported to 2.6, 2.7 and 3.1 ?

Has anyone looked at this? I'm trying to build gdb with Python enabled with mingw-w64 (Python 2.7.1 with manually created import libraries), but have to manually define MS_WIN64 in the CFLAGS. The patch only does what's right (i.e. define a macro that should be defined). David has nicely explained what needs to be done to reproduce the issue.

Thanks!

I'm also using this patch successfully (together with http://tdm-gcc.tdragon.net/).

Hi Martin

I have documented a build process for a Python package on MinGW-w64, including a requirement that this patch be applied. You might want to revisit it, given that your attempt to reproduce this bug earlier was unsuccessful.

http://ascend4.org/Building_ASCEND_for_64-bit_Windows

Please let me know if you're looking at it and if there's anything that needs to be clarified.

Cheers
JP

John: in the current versions of the toolchain, Python's configure fails for me. I follow steps 1..3 of "Steps to date". Then running ./configure fails saying that it does not work. I then tried alternatively these three approaches:

1. set PATH to include /mingw/mingw/bin
2. set CC to /mingw/mingw/bin/gcc.exe
3. set CC to /c/mingw/mingw/bin/gcc.exe

Even though I can run gcc -v just fine, configure fails with

configure:3593: checking whether the C compiler works
configure:3615: /mingw/mingw/bin/gcc    conftest.c  >&5
gcc.exe: error: CreateProcess: No such file or directory^
configure:3619: $? = 1
configure:3657: result: no

So apparently, mingw has some problem mapping the file name back to a Win32 path.

Marting, this issue is about building python extensions with mingw-w64 not about building python itself.

Martin, Ralf is right and my as previously linked is about building a python extension. I should have been more explicit about that.

FWIW I found that the configure scripts on MinGW-w64 generally work fine if you add a "--build=x86_64-w64-mingw32" argument on the ./configure command line. Then you should only add /mingw/bin to your path (and edit /etc/fstab to map c:/mingw64 to /mingw). Adding those subdirectories to the PATH doesn't seem to be successful; I suspect that those binaries are off the standard path for some reason, eg internal use by GCC only, or something (GCC seems to do some clever tricks with relative paths, so I'm sure it's important that you use the correct starting executable).

There's no need to discuss or even run configure scripts. Martin, please reread the OPs original message. It's easy enough to reason about the issue instead of trying to reproduce it.