MinGW-w64 - for 32 and 64 bit Windows

Hello Arthur722

2008/6/25 Arthur Norman <acn1@...>:
> What I wondered about was proposing a compiler flag so that regardless of
> the way the compiler had been built and was hosted it could be told which
> style (cygwin vs native windows) file names it should cope with? Would
> that be seen as generally useful and might it get into gcc?
>
> For what it is worth, when building 32-bit apps on Windows I am typically
> in cygwin and using "gcc -mno-cygwin" as my way of using mingw.
>
> Any advice/thoughts welcome!

Well, to have in gcc the ability to use native pathes wouldn't be so
bad. I am just not sure if the cygwin environment would treat the dos
pathes proper. But if this option (maybe something like
--no-cygwin-mapping) works, I think it has a good chance to get into
gcc. But why not simply using the native toolchain within cygwin? I
used this often and it worked for me well.
The -m32/-m64 is on my todo list. I hope I will find some time to
enable this. I agree that this would be of great help for mingw users.

Regards,
Kai

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

Hello Stuart,

thanks for reporting this. I corrected the winuser.h and the windows.h 
file. You can use svn version at revision 444.

Thanks,
Kai

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

On 6/3/08, Smith-Rowland, Edward M <ESmith-rowland@...> wrote:
> All,
>
> I am struggling with getting started in mingw 64-bit.  I am running WinXP64.  I downloaded and installed the latest Cygwin package and installed the base system and the (presumably 32-bit tool chain) and make.  I am hoping to install the 64-bit tool chain somewhere as well.
>
> I just installed the latest snapshot:
> mingw-w64-bin_i686-cygwin-1.5.25-12_20080521.tar.bz2
>
> I put the tarball in /usr in my cygwin setup and unpacked it.  It seemed to install compilers and headers and libraries in a parallel directory structure to the existing compiler.
>
> I commented all the interesting calls out of a C++ test driver.  What is left is a loop and some
> std::cout printing and some arithmetic.  I compile it with x86_64-pc-mingw32-g++ and it compiles no problem.
> When I run it it crashes during the first iteration.  This is the same behavior I've gotten from the previous snapshots of the 64-bit compilers too.

Some more information on this crash will be very helpful.  What
exactly do you see?


> I can compile static things with just gfortran but almost anything involving C++ just fails.  I can compile and run "Hello, World" in 64-bits
>
> The test driver compiles and runs just fine under the base cygwin compiler.
>
> How/where are we supposed to install these compilers?  Do I have the right package?

You can install them anywhere, they don't have to be in /usr.  You can
for instance put them in /mytoolchain or whatever.  Then just put
/mytoolchain/bin in your PATH, and execute
x86_64-pc-mingw32-(toolname) as you have done.

If you're using cygwin, you need to use the same version as the
cygwint hat you have.  I think cygwin updated their runtime dll to a
version newer that 1.5.25-12, which is what that particular version
you downloaded is compiled against.

-----Original Message-----
From: NightStrike [mailto:nightstrike@...]
Sent: Wed 6/4/2008 9:22 AM
To: Smith-Rowland, Edward M
Cc: mingw-w64-public@...
Subject: Re: [Mingw-w64-public] Starting with 64-bit mingw...
 
On 6/3/08, Smith-Rowland, Edward M <ESmith-rowland@...> wrote:
> All,
>
> I am struggling with getting started in mingw 64-bit.  I am running WinXP64.  I downloaded and installed the latest Cygwin package and installed the base system and the (presumably 32-bit tool chain) and make.  I am hoping to install the 64-bit tool chain somewhere as well.
>
> I just installed the latest snapshot:
> mingw-w64-bin_i686-cygwin-1.5.25-12_20080521.tar.bz2
>
> I put the tarball in /usr in my cygwin setup and unpacked it.  It seemed to install compilers and headers and libraries in a parallel directory structure to the existing compiler.
>
> I commented all the interesting calls out of a C++ test driver.  What is left is a loop and some
> std::cout printing and some arithmetic.  I compile it with x86_64-pc-mingw32-g++ and it compiles no problem.
> When I run it it crashes during the first iteration.  This is the same behavior I've gotten from the previous snapshots of the 64-bit compilers too.

Some more information on this crash will be very helpful.  What
exactly do you see?


> I can compile static things with just gfortran but almost anything involving C++ just fails.  I can compile and run "Hello, World" in 64-bits
>
> The test driver compiles and runs just fine under the base cygwin compiler.
>
> How/where are we supposed to install these compilers?  Do I have the right package?

You can install them anywhere, they don't have to be in /usr.  You can
for instance put them in /mytoolchain or whatever.  Then just put
/mytoolchain/bin in your PATH, and execute
x86_64-pc-mingw32-(toolname) as you have done.

If you're using cygwin, you need to use the same version as the
cygwint hat you have.  I think cygwin updated their runtime dll to a
version newer that 1.5.25-12, which is what that particular version
you downloaded is compiled against.


The crash is very quiet.
I have this:

    for ( int r = 1; r < 10; ++r )
    {
        float rrate = r * 10.0F;
        std::cout << std::endl;
        std::cout << "  Rain rate = " << rrate << " mm/hr" << std::endl;
    }

The output is:
-----------------------------------

  Rain rate = 
-----------------------------------
without a newline at the end.  It bombs at outputting the float.  No messages are put out.

Now I'm trying to download and build the tool chain from svn with a script.  When I run this makebuildroot.sh it starts with a cvs download of binutils.  It times out.  Now it's been a while since I've used cvs and I never dug into it that much anyway.  Is there anything I need to set up for this?

I'm hoping that a bootstrap of everything into some build directory would get past any version inconsistencies.

Thanks,

Ed

On 6/4/08, Smith-Rowland, Edward M <ESmith-rowland@...> wrote:
>
>
>
> -----Original Message-----
> From: NightStrike [mailto:nightstrike@...]
> Sent: Wed 6/4/2008 9:22 AM
> To: Smith-Rowland, Edward M
> Cc: mingw-w64-public@...
> Subject: Re: [Mingw-w64-public] Starting with 64-bit mingw...
>
> On 6/3/08, Smith-Rowland, Edward M <ESmith-rowland@...> wrote:
> > All,
> >
> > I am struggling with getting started in mingw 64-bit.  I am running WinXP64.  I downloaded and installed the latest Cygwin package and installed the base system and the (presumably 32-bit tool chain) and make.  I am hoping to install the 64-bit tool chain somewhere as well.
> >
> > I just installed the latest snapshot:
> > mingw-w64-bin_i686-cygwin-1.5.25-12_20080521.tar.bz2
> >
> > I put the tarball in /usr in my cygwin setup and unpacked it.  It seemed to install compilers and headers and libraries in a parallel directory structure to the existing compiler.
> >
> > I commented all the interesting calls out of a C++ test driver.  What is left is a loop and some
> > std::cout printing and some arithmetic.  I compile it with x86_64-pc-mingw32-g++ and it compiles no problem.
> > When I run it it crashes during the first iteration.  This is the same behavior I've gotten from the previous snapshots of the 64-bit compilers too.
>
> Some more information on this crash will be very helpful.  What
> exactly do you see?
>
>
> > I can compile static things with just gfortran but almost anything involving C++ just fails.  I can compile and run "Hello, World" in 64-bits
> >
> > The test driver compiles and runs just fine under the base cygwin compiler.
> >
> > How/where are we supposed to install these compilers?  Do I have the right package?
>
> You can install them anywhere, they don't have to be in /usr.  You can
> for instance put them in /mytoolchain or whatever.  Then just put
> /mytoolchain/bin in your PATH, and execute
> x86_64-pc-mingw32-(toolname) as you have done.
>
> If you're using cygwin, you need to use the same version as the
> cygwint hat you have.  I think cygwin updated their runtime dll to a
> version newer that 1.5.25-12, which is what that particular version
> you downloaded is compiled against.
>
>
> The crash is very quiet.
> I have this:
>
>    for ( int r = 1; r < 10; ++r )
>    {
>        float rrate = r * 10.0F;
>        std::cout << std::endl;
>        std::cout << "  Rain rate = " << rrate << " mm/hr" << std::endl;
>    }
>
> The output is:
> -----------------------------------
>
>  Rain rate =
> -----------------------------------
> without a newline at the end.  It bombs at outputting the float.  No messages are put out.
>
> Now I'm trying to download and build the tool chain from svn with a script.  When I run this makebuildroot.sh it starts with a cvs download of binutils.  It times out.  Now it's been a while since I've used cvs and I never dug into it that much anyway.  Is there anything I need to set up for this?
>
> I'm hoping that a bootstrap of everything into some build directory would get past any version inconsistencies.


Well, first you need cvs installed.  Do you have any weird proxy
settings that need to be configured?  You can also use the --nocvs
option to just d/l a binutils snapshot.  Use --help to see all
options.

On a sidenote, though, you can also try to run gdb and do a backtrace
on the crash to see where it's dying.

On 6/2/08, Erik de Castro Lopo <mle+win@...> wrote:
> Hi all,
>
> I've looked on the sourceforge download page:
>
>     http://sourceforge.net/project/showfiles.php?group_id=202880
>
> which offers a complete toolchain snapshot, but looking in the
> SVN repo, I can't find anything that really looks like the source
> code to generate this snapshot.
>
> Is that kept somewhere else or can I just not see it?

Hi, Erik,

The source code on our website is one part of the complete toolchain.
The toolchain consists of binutils, gcc, and some sort of runtime
libraries / headers.  Our project makes the third part.  Binutils is
available at http://www.gnu.org/software/binutils/ and gcc is
available at http://gcc.gnu.org/

I build everything with a script that's in the svn repo under
experimental/buildsystem/makebuildroot.sh

That script will download sources from the 3 repositories and build
the complete toolchain snapshot that is available on the mingw-w64 sf
site.

Any questions on the above, just ask.  Thanks for using our site!

NightStrike wrote:

> I build everything with a script that's in the svn repo under
> experimental/buildsystem/makebuildroot.sh

Ahh, cool, thats what i was looking for.

I tried the Linux to win64 cross compiler about a month ago and
it didn't want to compiled my project. However, I just grabbed
the 20080531 tarball and it compiles. I still have to find a 
way to *test* the actual binaries.

Thats some damn good progress. Thanks.

Cheers,
Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"... there's something really scary about a language (C++) where
copying state from one object to another is this complicated"
-- Richard Gillam

On 6/2/08, Erik de Castro Lopo <mle+win@...> wrote:
> NightStrike wrote:
>
> > I build everything with a script that's in the svn repo under
> > experimental/buildsystem/makebuildroot.sh
>
> Ahh, cool, thats what i was looking for.
>
> I tried the Linux to win64 cross compiler about a month ago and
> it didn't want to compiled my project. However, I just grabbed
> the 20080531 tarball and it compiles. I still have to find a
> way to *test* the actual binaries.

We got a copy of Vista64 Ultimate donated, and I have been opening
access to people that need it for that reason - to test their code.
If you want to make arrangements for that, send me a message offlist
or join the irc at irc.oftc.net/#mingw-w64

> Thats some damn good progress. Thanks.

Thank Kai, not me.  I just talk a lot -- he does all the work :)

NightStrike wrote:

> > Thats some damn good progress. Thanks.
> 
> Thank Kai, not me.  I just talk a lot -- he does all the work :)


Thanks Kai! Excellent work.


Cheers,
Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Web (hosting), security and high-performance computing are the
three areas where Linux has more strength." --
Bob Muglia, senior VP in charge of Windows Server development.
http://news.com.com/Microsoft+targets+Apache+Web+server/2100-1010_3-5735805.html

> - I added a "mingw64" line to Configure and (think I) told it to use
> .exe
>   extension for compiling. Nothing surprising here, I think. Note that
>   you currently need to "Configure mingw64 no-asm no-hw".

IIUC, the current position on naming is that mingw64 shouldn't be  
used, but rather the full triplet x86_64-pc-mingw or, as a simpler  
name, mingw-w64.

FX

-- 
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Hi Stefan, FX,

> > - I added a "mingw64" line to Configure and (think I) told it to use
> > .exe
> >   extension for compiling. Nothing surprising here, I think. Note that
> >   you currently need to "Configure mingw64 no-asm no-hw".
> 
> IIUC, the current position on naming is that mingw64 shouldn't be 
> used, but rather the full triplet x86_64-pc-mingw or, as a simpler 
> name, mingw-w64.
The full host triplet is x86_64-*-mingw32, so a check for x86_64-*-mingw* 
is fine, too. The postfix 32 to the triplet name is necessary, because not 
all names in gcc configure are modified until now. Otherwise you may loose 
some configuration options.

Stefan, thanks for your contribution. I will comment soon on it.

Cheers,
  Kai

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

Hi Stefan,
>                Hi,
> 
> I just tried to compile OpenSSL-0.9.8h with mingw-w64 (see
> http://sourceforge.net/projects/mingw-w64/) and needed a couple
> of changes to the source code (see attached patch).
> 
> Some notes:
> - I added a "mingw64" line to Configure and (think I) told it to use
> .exe
>   extension for compiling. Nothing surprising here, I think. Note that
>   you currently need to "Configure mingw64 no-asm no-hw".
> 
> - windows.h apparently includes wincrypt.h (no idea whether that's
>   specific to that compiler, but it seems so ...), so I needed to 
>   #undefine a couple of names messed up by wincrypt.h
>   (patches to rand.h, x509.h and e_os.h).
> 
> - It's using a very recent snapshot of gcc, so there also is the
>   problem in e_os2.h, that has already been reported for
>   gcc-4.3: the compiler complains about the same variable
>   being declared as both extern and static - so I changed that
>   to use static both times - but I'm not really sure what's the
>   correct thing to do here.

The cygwin specific options - like "-mno-cygwin" - in the "mingw64" line 
of configure are not necessary. There is no cygwin for 64-bit for now 
IIRC.

Thank you for porting.

Regards,
  Kai

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

Hi,

In reply to various mails, let me add some comments:

> > - I added a "mingw64" line to Configure and (think I) told it to use
> > .exe
> > extension for compiling. Nothing surprising here, I think. Note that
> > you currently need to "Configure mingw64 no-asm no-hw".

Note that OpenSSL's "Configure" is not autoconf-based, so the usual
triplets are irrelevant (and not used for the other platforms either).

> > - windows.h apparently includes wincrypt.h (no idea whether that's
> > specific to that compiler, but it seems so ...), so I needed to
> > #undefine a couple of names messed up by wincrypt.h
> > (patches to rand.h, x509.h and e_os.h).

OpenSSL developpers seem to rather consider this a mingw_w64
bug, at least I got one reply on that list indicating that MS samples
normally explicitly include both headers...

> The cygwin specific options - like "-mno-cygwin" - in the "mingw64"
> line of configure are not necessary. There is no cygwin for 64-bit for
> now IIRC.

I just tried to change the original "mingw" (for 32 bit) configuration
line
as little as possible. But no, I didn't find any other gcc based project

targetting Win64 either. BTW, what platform exactly are you targetting:
x86_64 only, or (T)itanic (aka IA64) as well? In the longer run,  I
mean.
ATM it's appears to obviously be x86_64 only.

 > Thank you for porting.

Well that's a bit of an exaggeration - I only made it compile, I
currently
have no idea whether or how well it works - that's the nice thing about
a
cross-compiler... ;-)
At least, it's not using existing assembly code, which certainly is not
so
good, but once it does at least compile, that might give other people
(more
fluent with assembler and it's error messages) a better starting point. 

      Regards,
           Stefan

On 6/3/08, Stefan.Neis@... <Stefan.Neis@...> wrote:
>         Hi,
>
> In reply to various mails, let me add some comments:
>
> > > - I added a "mingw64" line to Configure and (think I) told it to use
> > > .exe
> > > extension for compiling. Nothing surprising here, I think. Note that
> > > you currently need to "Configure mingw64 no-asm no-hw".
>
> Note that OpenSSL's "Configure" is not autoconf-based, so the usual
> triplets are irrelevant (and not used for the other platforms either).

The reason that you have to use the entire target triplet is that that
is how the executables are named.  The executable for the cross
compiler under any host is "x86_64-pc-mingw32-gcc".  Eventually, if we
ever get around to dropping the 32, it will be just
"x86_64-pc-mingw-gcc".  So presumably you are configuring for the
"target triplet" system, which will translate into the canonicalized
name of the executable.


> > > - windows.h apparently includes wincrypt.h (no idea whether that's
> > > specific to that compiler, but it seems so ...), so I needed to
> > > #undefine a couple of names messed up by wincrypt.h
> > > (patches to rand.h, x509.h and e_os.h).
>
> OpenSSL developpers seem to rather consider this a mingw_w64
> bug, at least I got one reply on that list indicating that MS samples
> normally explicitly include both headers...
>
> > The cygwin specific options - like "-mno-cygwin" - in the "mingw64"
> > line of configure are not necessary. There is no cygwin for 64-bit for
> > now IIRC.
>
> I just tried to change the original "mingw" (for 32 bit) configuration
> line as little as possible.

For mingw, you don't need those options either.  You can change it for both.

> But no, I didn't find any other gcc based project
> targetting Win64 either. BTW, what platform exactly are you targetting:
> x86_64 only, or (T)itanic (aka IA64) as well? In the longer run,  I
> mean. ATM it's appears to obviously be x86_64 only.

If we can get some IA64 hardware, maybe we can create a roadmap.  Know
any donors?

>  > Thank you for porting.
>
> Well that's a bit of an exaggeration - I only made it compile, I
> currently have no idea whether or how well it works - that's the nice thing about
> a cross-compiler... ;-)
> At least, it's not using existing assembly code, which certainly is not
> so good, but once it does at least compile, that might give other people
> (more fluent with assembler and it's error messages) a better starting point.

You're handling the first, and very important, step, so don't sell
yourself short!

----- Original Message ----
> From: NightStrike <nightstrike@...>
> To: Matthew Bentham <matthew_bentham@...>
> Cc: mingw-w64-public@...
> Sent: Tuesday, June 3, 2008 8:06:13 AM
> Subject: Re: [Mingw-w64-public] Cannot #include <windows.h>
> 
> On 5/23/08, Matthew Bentham wrote:
> > My experience with the binary builds from mingw64 SourceForge has also been 
> that they suffer from the Vista access() problem, as we discussed on this 
> mailing list on Feb 24th 2008.  I've included my notes from the time (discussing 
> the state of GCC bug 33281 with FXCoudert and NightStrike) below.  Unfortunately 
> I haven't had time to look at it myself since then, I  use a compiler that I 
> built from source myself and explicitly define __USE_MINGW_ACCESS when doing so.
> 
> 
> 
> Matthew,
> 
> Please try the latest build dated 0528 for the native toolchain, and
> make sure that your version of Vista is at SP1 (Thanks, Sisyphus!)
> Please let me know if your problems go away (well, not all of your
> problems... but any relating to mingw-w64!)


Yep, works fine now.  Very mysterious!  I wonder what changed in SP1, and I wonder what I was doing differently in my build that made it work pre SP1.  Maybe the access() problem doesn't even exist in SP1.

Thanks all,

Matthew

----- Original Message ----- 
From: "Matthew Bentham" <matthew_bentham@...>

.
.
>  Maybe the access() problem doesn't even exist in SP1.

Oh, shit ... I think that's right !!

Before installing SP1, with a certain MinGW32 installation, I got:

-------------------
C:\_64\C>\strawberry\c\bin\gcc -o try.exe try.c
gcc: installation problem, cannot exec `cc1': No such file or directory

C:\_64\C>
-------------------

Having now installed SP1, using the very same MinGW32 installation, I get:

-------------------
C:\_64\C>\strawberry\c\bin\gcc -o try.exe try.c

C:\_64\C>try
8

C:\_64\C>
-------------------

That's without having changed either that MinGW32 installation or 
C:\_64\C\try.c in any way.

Cheers,
Rob

On 6/2/08, Sisyphus <sisyphus1@...> wrote:
>
> ----- Original Message ----- From: "NightStrike" <nightstrike@...>
> To: "Sisyphus" <sisyphus1@...>
> Cc: <mingw-w64-public@...>
> Sent: Tuesday, June 03, 2008 1:05 AM
> Subject: Re: [Mingw-w64-public] Cannot #include <windows.h>
> .
> .
> > I'm running with SP1
> > installed and all the recent updates.
> >
>
> Windows Update installs updates every day - but doesn't install SP1.
> Installing SP1 seems to have fixed the problem ... which is, no doubt, a
> relief to *both* of us. (At least that test program builds and runs
> correctly.)
>
> Thanks, NightStrike.

A relief indeed!  I had no idea whatsoever what else to suggest!

I guess at this point I should put somewhere on the site that Vista
support requires SP1.