2012/8/16 Damon Register <[email protected]>
> On 8/16/2012 12:15 PM, Kai Tietz wrote:
> > I re-directed you to the mingw-w64 list. MinGW.org doesn't have
> Thank you for the quick reply and for pointing me in the right direction.
> You have already answered a few of my questions.
>
> > reason you will get best answers by asking on our list. Also be aware
> > that mingw.org and mingw-w64 are two different ventures and mingw.org
> So that answers one of my questions and now I understand that these
> two projects aren't used together.
>
> > First, mingw-w64 isn't just for cross-compilers. Not sure how this
> > impression came up, we are supporting 32-bit and 64-bit as cross and
> I have visited so many places that I am not sure what I read to get
> that impression.
>
> > If you want to build native 64-bit applications, you have to use
> > mingw-w64's toolchains, as mingw.org simply doesn't support this
> Ok, I understand now. Thanks
>
> > mingw-w64 32-bit compilers. There are some feature differences. For
> > further information see mingw-w64's Wiki.
> With that, I think I understand a bit more.
>
> I have been going over the General Usage Instructions page a few times
> but I am having a hard time matching the instructions with what is packed
> in mingw-w64-1.0-bin_i686-mingw_20110822.zip
> I see there are two directories whose contents are equal
>
> mingw-w64-1.0-bin_i686-mingw_20110822/x86_64-w64-mingw32
> mingw-w64-1.0-bin_i686-mingw_20110822/mingw
>
>
That's true, and the /mingw directory can be safely removed. It's an
ancient holdover from the other project (MinGW.org) that just causes
everything to feel bloated. Delete and forget ;-)
> It also appears that the
> mingw-w64-1.0-bin_i686-mingw_20110822/x86_64-w64-mingw32/bin
> contents are a subset of
> mingw-w64-1.0-bin_i686-mingw_20110822/bin
>
>
That's not true; they look the same, but are used differently. Only
top-level bin (i.e. "mingw-w64-1.0-bin_i686-mingw_20110822/bin") should be
appended or prepended to PATH and these executables are the ones you want
to use. The other ones are for internal use by the compiler, and should not
be called directly.
> I am sure there is a good reason for that arrangement but I am confused.
> Would I be correct in understanding that in this case I put
> mingw-w64-1.0-bin_i686-mingw_20110822/bin
> in the path and use
> -I/mingw-w64-1.0-bin_i686-mingw_20110822/x86_64-w64-mingw32/include
> for the include path?
>
This is not necessary. GCC knows where to find system headers. Just call
"gcc" or "g++" like on any other system, and it will find everything (the
C, GCC, and C++ standard headers) all by itself. 3rdparty libraries need
such a switch though.
Alos note that the (windows) autobuilds (like the one you downloaded) are
currently (unfortunately) quite outdated, and always built as
cross-compiler. You can verify this by seeing that all "gcc", "g++",
"gfortran", etc. executables are prefixed with "i686-w64-mingw32-" or
"x86_64-w64-mingw32-". This might complicate using it easily with a number
of projects. There are two things you can do to rid yourself of the
prefixes:
1. rename/copy the prefixed executables to duplicate files without the
prefix.
2. Download a personal build, like my release builds that are full native
compilers (find the i686-....-win32
here<https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.7-release/>and
the x86_64....-win64
here<https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.7-release/>).
You can also browse for other people's builds (like sezero's, which are
still stable as a rock, though a tad old by now), although mine are the
most up to date and I plan to keep them nice and tidily updated.
My personal builds also include stable GCC version, GDB (debugger),
mingw32-make, and OpenMP support.
If you have any more questions, feel free to ask.
Ruben
> Damon Register
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Mingw-w64-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
