MinGW-w64 - for 32 and 64 bit Windows

Hello Patrick,

2009/4/24 patrick flaherty <patf@...>:
>
> Hi,
>
> I successfully built the Sourceforge pyOpenSSL project with mingw32.
>
> But I'm on a 64-bit machine and have had problems with loading the project's
> DLLs at runtime (on a 32 bit machine loading the DLLs works fine) and when I
> found mingw-64 on sourceforge thought I'd give it a try and see if it helped
> me out on my 64 bit machine.  The code will eventually need to be deployed
> on 64 bit machines.
>
> Downloaded a recent toolchain build.  The instructions I used are here:
>
> http://mingw-w64.wiki.sourceforge.net/Installation+of+binary+toolchain+packages
>
> So I can copy the whole of the toolchain directory structure to any
> directory location; add the bin directory within the toolchain to my PATH;
> and at least according to the instructions above I should be good to go.
>
> Yeah right.

Yes, so far everything seems ok. Which toolchain you are using and
which build environment?

> The compile quickly exits with:
>
> L:\MyID\Python\pyOpenSSL>setup.py build_ext -Ic:\openssl\include -c
> x86_64-pc-mingw32
> running build_ext
> error: don't know how to compile C/C++ code on platform 'nt' with
> 'x86_64-pc-mingw32' compiler

Hmm, what means 'nt' here?

> Looking around the web, I believe x86_64-pc-mingw32 to be the correct name
> to be use.  However when I look under where I installed mingw64, I find 3
> bin directories:
>
> pat$ pwd
> /cygdrive/d/mingw64
> pat$ find . -name bin
> ./bin
> ./mingw/bin
> ./x86_64-pc-mingw32/bin
> pat$

Yes, (in fact there are just two directories, because mingw is a link
to x86_64-pc-mingw32) this absolutly correct. In top bin directory you
find the binaries you should use (and you should just add this
directory to your path). The other are just for internal toolchain's
sake and you should just keep them.

> I originally set the location in PATH to the first of the 3.  Didn't work.
> And then I tried #s 2 and 3 and they provoked exactly the same error from
> the build.
>
> pat

I assume, that you are using the mingw 32-bit to 64-bit cross-compiler
toolchain. So there are two different possible errors I see here.
First, the python script doesn't call the proper toolchain (prefix of
all tools is x86_64-pc-mingw32- ...), or you are passing 32-bit only
parameters to 64-bit compiler.

If you can give me some more details about this issue, I'll try to help.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Hello Kai - thanx for your response.

Kai Tietz wrote:
> Hello Patrick,
>
> 2009/4/24 patrick flaherty <patf@...>:
>   
>> Hi,
>>
>> I successfully built the Sourceforge pyOpenSSL project with mingw32.
>>
>> But I'm on a 64-bit machine and have had problems with loading the project's
>> DLLs at runtime (on a 32 bit machine loading the DLLs works fine) and when I
>> found mingw-64 on sourceforge thought I'd give it a try and see if it helped
>> me out on my 64 bit machine.  The code will eventually need to be deployed
>> on 64 bit machines.
>>
>> Downloaded a recent toolchain build.  The instructions I used are here:
>>
>> http://mingw-w64.wiki.sourceforge.net/Installation+of+binary+toolchain+packages
>>
>> So I can copy the whole of the toolchain directory structure to any
>> directory location; add the bin directory within the toolchain to my PATH;
>> and at least according to the instructions above I should be good to go.
>>
>> Yeah right.
>>     
>
> Yes, so far everything seems ok. Which toolchain you are using and
> which build environment?
>
>   

The file I downloaded and installed from was 
mingw-w64-bin_i686-mingw_20090420.zip

>> The compile quickly exits with:
>>
>> L:\MyID\Python\pyOpenSSL>setup.py build_ext -Ic:\openssl\include -c
>> x86_64-pc-mingw32
>> running build_ext
>> error: don't know how to compile C/C++ code on platform 'nt' with
>> 'x86_64-pc-mingw32' compiler
>>     
>
> Hmm, what means 'nt' here?
>
>   

'nt' as in Windows NT.  I assume this env variable name indicates to 
whatever that what's it's on is a server version of Windows.

In my case that's Windows Server 2008 R2.  This is the latest version of 
the server OS.  I don't know if it's generally available - I got it 
through my MSDN contract.

The R2 indicates that it's WS 2008 rewritten with the Windows 7 OS core.

The OS has been problematic in a number of ways.  But I've pretty much 
successfully dealt with all problems that have arisen so far.

>> Looking around the web, I believe x86_64-pc-mingw32 to be the correct name
>> to be use.  However when I look under where I installed mingw64, I find 3
>> bin directories:
>>
>> pat$ pwd
>> /cygdrive/d/mingw64
>> pat$ find . -name bin
>> ./bin
>> ./mingw/bin
>> ./x86_64-pc-mingw32/bin
>> pat$
>>     
>
> Yes, (in fact there are just two directories, because mingw is a link
> to x86_64-pc-mingw32) this absolutly correct. In top bin directory you
> find the binaries you should use (and you should just add this
> directory to your path). The other are just for internal toolchain's
> sake and you should just keep them.
>
>   

OK: so ./bin is the one I want (in PATH).

>> I originally set the location in PATH to the first of the 3.  Didn't work.
>> And then I tried #s 2 and 3 and they provoked exactly the same error from
>> the build.
>>
>> pat
>>     
>
> I assume, that you are using the mingw 32-bit to 64-bit cross-compiler
> toolchain. So there are two different possible errors I see here.
> First, the python script doesn't call the proper toolchain (prefix of
> all tools is x86_64-pc-mingw32- ...), or you are passing 32-bit only
> parameters to 64-bit compiler.
>
> If you can give me some more details about this issue, I'll try to help.
>
> Cheers,
> Kai
>
>   

The problem, as I see it, is that the build is somehow 'not finding' 
mingw64  (or more correctly: it's not recognizing x86_64-pc-mingw32) .  
I have a fair amount of experience with cygwin and gcc but this is 
something new to me (how gcc 'finds' the various things specified).

With mingw32 I would specify the build as:

python setup.py build_ext -Ic:/openssl/include -c mingw32

And the relevant parts of the gcc would translate to:
gcc .exe -mno-cygwin -mdll -O -Wall -I...

This built successfully.  However it didn't run because at runtime the 
DLLs wouldn't load.  I transferred that build from my 64 bit machine to 
a 32 bit machine; the DLLs loaded fine; and the python program ran 
successfully.

pat

Here's an idea.  So that I can get my arms around mingw64.

What would be the barebones gcc command, using mingw64, to build a 
sample hello.c?

This would, in effect, strip out any python considerations.

thanx - pat

> What would be the barebones gcc command, using mingw64, to build a
> sample hello.c?

On a 64-bit Windows system, presumably:

gcc -o hello.exe hello.c.

Using a cross-compiler:

x86_64-pc-mingw32-gcc -o hello.exe hello.c

--tml

Thanx Tor - did as you instructed.

The hello.exe compiled with x86_64-pc-mingw32-gcc is about 10X the size 
of the one compiled with simply gcc which would seem to indicate that 
the former is a 64 bit image and the latter 32.

But how does one check an image to directly to see if it's compiled 32 
or 64 bits?  (I've googled this some already but haven't yet found a 
good answer).

Tried objdump -i on both images.  And they both reported exactly the 
same results.  With briefly, lots of references to i386 and no 
references to, say, i686.  But objdump is probably not the tool I want.

It's been many years since I more than dabbled in UNIX land.

thanx - pat



Tor Lillqvist wrote:
>> What would be the barebones gcc command, using mingw64, to build a
>> sample hello.c?
>>     
>
> On a 64-bit Windows system, presumably:
>
> gcc -o hello.exe hello.c.
>
> Using a cross-compiler:
>
> x86_64-pc-mingw32-gcc -o hello.exe hello.c
>
> --tml
>
>
>

Starting with this:

http://oldwiki.mingw.org/index.php/Python%20extensions

I believe the problem to be in distutils.  Something needs to be 
modified to accommodate  x86_64-pc-mingw32-gcc.

So far, from distutils, I've been through msvccompiler.py, 
msvc9compiler.py and cccompiler.py.  I'm making progress but haven't 
fully gotten there yet.

pat

2009/4/25 patrick flaherty <patf@...>:
> Starting with this:
>
> http://oldwiki.mingw.org/index.php/Python%20extensions
>
> I believe the problem to be in distutils.  Something needs to be
> modified to accommodate  x86_64-pc-mingw32-gcc.
>
> So far, from distutils, I've been through msvccompiler.py,
> msvc9compiler.py and cccompiler.py.  I'm making progress but haven't
> fully gotten there yet.
>
> pat

Well, by configure you would specify it via the --host argument. I
assume that you have to make sure that all gcc, g++, as, windres, ld,
... calls are getting prefixed by the target triplet part. By this you
could use here nearly any cross-compilers.
But I am not very familiar with this python build script, so I am here
not much help.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

> But how does one check an image to directly to see if it's compiled 32 or 64
> bits?

objdump -h for instance. An objdump built for just 32-bit mingw won't
even recognize a 64-bit binary. An objdump built for 64-bit mingw will
tell you that a 32-bit binary is "file format pei-i386" and a 64-bit
is "file format pei-x86-64".

If you have some good and up-to-date version of the "file" command it
would also be useful.

(The one I happen to have isn't useful enough. It just says that a
64-bit executable is a "MS Windows PE" and doesn't point out that it
is a 64-bit one. For a 32-bit one it does say "MS Windows PE 32-bit
Intel 80386".)

--tml

Hello Wolfgang,

2009/4/3 Wolfgang Glas <wolfgang.glas@...>:
> Hi all,
>
>  I recently moved from the 20090307 to the 20090326 snapshot of mingw-w64 and
> recompiled my whole library stack and finally I managed to get rid of the last
> few remaining spuriour crashes in 64 bit binaries ;-)
>
>  Big hands and many thanks to all, who have contributed to this project ;-))
>
>  Since there haven't been pushlished any newer snapshots 20090326, I
> anticipate, that this is related to the gcc-4.4 branch, which has been created
> on March, 27th and that the next mingw-w64 release we will see is an official
> gcc-4.4.0 release.
>
>  For our part, we are using Linux(ubuntu) to cross-compile code for win32 and
> win64, so we'd like to have debian-packages of all of the mingw-w64 stuff
> targetting at win32 and win64 as well as debian-packages for all the open source
> libraries we and others have ported to mingw-w64.
>
>  I will start creating such debian packages inside a launchpad PPA when gcc-4.4
> is available. As this is going to be a mid-sized effort, I invite others to
> contribute ;-) If someone is interested, please step up, so I can create a new
> launchpad group and a new group PPA in order to start.
>
>  As a starting point I'd like to have a copy of the automated build script,
> which created the snapshot releases. Would it be possible for Kai or some other
> guy send me the beast vie e-mail?
>
>  TIA,
>
>    Wolfgang
>

Thanks for your words. The script you search is to be found in our
experimental tree. If you have any question about it, don't hesitate
to ask Mook or NightStrike about it.

Thanks,
Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination