Now wait a minute, I never said such a thing. I said that the MinGW-w64 binaries are Cygwin-based now. Meaning, the MinGW they release needs Cygwin DLLs to run.
The output they generate is still native Win32 binaries, which does _not_ require Cygwin. (Anything else would be silly, since you could then just use the normal Cygwin-provided gcc, and not MinGW.) Now, I do see that the latest "official release" actually comes from the personal(!) build directory of a Ray Linn, and does not require Cygwin. (I only noticed it when looking at the files page, and it says "Looking for the latest version? Download mingw-w64-gcc-4.6.3-runtime-2.0.1-static-ada-20120321.7z (28.2 MB)", which happens to point to http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/ray_linn/) But personally I much better like the structure, consistency, and variety of the mingwbuilds project. You have to admit looking at http://sourceforge.net/projects/mingwbuilds/files/windows-host/ it feels much cleaner and professional. The MinGW-w64 project _feels_ as if it doesn't have a clear mission. (I'm not saying they don't have one.) -- .marius On 20/04/2012 06:09, ext Pau Garcia i Quiles wrote: > Hi, > > I'd say you are confusing "mingw-w64 is available in Cygwin" (like > mingw.org is) with "mingw-w64-produced binaries need Cygwin DLLs". > > I've been using mingw-w64 for zsync on Windows ( > https://www.assembla.com/spaces/zsync-windows ) for quite some time > and the zsync.exe and zysncmake.exe binaries work without Cygwin DLLs. > > > > On Fri, Apr 20, 2012 at 12:46 PM,<marius.storm-ol...@nokia.com> wrote: >> Take another look. They haven't produced pure MinGW binary releases >> since the end of 2011. The front page says "The mingw-w64 toolchain has >> been officially added to Cygwin mirrors", and when you look under the >> "Releases" (and then under "Automated Builds") section to the left on >> the front page, you will see that only Cygwin-based binaries (and >> linux-based cross-compilers) are now being produced. And yes, if you run >> 'depends' on those binaries, they do require the Cygwin DLLs. >> >> I'm sure you can download the sources and built it yourself without the >> need to be Cygwin-based, but Daniel didn't want to do that, he wanted >> binaries he could just include. >> >> The MinGWbuilds project produces much cleaner downloads, and also a nice >> set of GCC versions you can choose from. And yes, the MinGWbuilds ones >> are also dual target (x86/x64), just provide the -m32/-m64 flags as >> normal. The binaries for x86 and x64 are just describing the host, and >> what they target by default. (More details on that on the previous site: >> http://code.google.com/p/mingw-builds/) >> >> -- >> .marius >> >> >> On 19/04/2012 22:16, ext 1+1=2 wrote: >>> No, MinGW-w64 doesn't depend on Cygwin. >>> >>> http://openfoamwiki.net/index.php/Tip_Cross_Compiling_OpenFOAM_in_Linux_For_Windows_with_MinGW#Differences_between_mingw32_and_mingw-w32_versions >>> >>> Mingw-w64 began as a spin-off from the mingw.org project, with the >>> original intent of building for 64-bit targets. Nonetheless, mingw-w64 >>> has retro-compatibility with the 32bit MinGW version, thus enabling a >>> 2-in-1 build package for 32 and 64bit Windows systems. >>> >>> On Thu, Apr 19, 2012 at 7:59 PM,<marius.storm-ol...@nokia.com> wrote: >>>> On 19/04/2012 17:06, ext 1+1=2 wrote: >>>>>> From the homepage of project, http://mingwbuilds.sourceforge.net/ >>>>> >>>>> This is the MinGW-builds project ("mingwbuilds") >>>>> This project was registered on SourceForge.net on Mar 30, 2012, and >>>>> is described by the project team as follows: >>>>> Snapshots and releases builds of the MinGW compiler that use CRT >>>>> & WinAPI from the mingw-w64 project. Builds support the following >>>>> technologies: - OpenMP - LTO - Graphite - std Concurrency >>>>> >>>>> So, the official homepage should be: http://mingw-w64.sourceforge.net/ >>>> >>>> No, the first project is not related to the other. MinGW-builds was just >>>> recently moved from http://code.google.com/p/mingw-builds/ to >>>> http://sourceforge.net/projects/mingwbuilds, hence the new date on the >>>> Sourceforge project page. >>>> >>>> MinGW-builds only snags the *CRT* and *WinAPI* parts from the MinGW-w64 >>>> project, but is otherwise unrelated. >>>> >>>> MinGW-w64 distributes MinGW binaries which require Cygwin to run, while >>>> the MinGW-builds project distributes native Win32 versions of MinGW. >>>> Only the latter is acceptable to the Qt Project. >>>> >>>> -- >>>> .marius >>>> >>>> >>>>> Regards, >>>>> >>>>> Debao >>>>> >>>>> >>>>> On Thu, Apr 19, 2012 at 2:32 PM,<marius.storm-ol...@nokia.com> wrote: >>>>>> If you click the link in Daniels initial email, and onto the windows >>>>>> host directory, you would see that the have both the 4.7.0 release and >>>>>> the 4.7.1 prerelease as binaries already. >>>>>> >>>>>> -- >>>>>> Sent from my Nokia N9 >>>>>> >>>>>> On 4/19/12 16:14 ext Mark wrote: >>>>>> 2012/4/19<daniel.molken...@nokia.com> >>>>>> >>>>>> Hi Everyone, >>>>>> >>>>>> After several complains from the community that GCC 4.4 shipped with >>>>>> both Creator and the Qt SDK is fairly outdated (and not C++11 >>>>>> compliant), we are going to ship a mingw.org-based GCC 4.6.2 with the >>>>>> next Qt Creator release. Even though we verified that this works with >>>>>> the MinGW 4.4 compiled Qt releases from the Qt SDK, I think we should >>>>>> agree on a common version. Thus, I want to come to an agreement with all >>>>>> relevant stakeholders in the Qt Project on which MinGW to ship. >>>>>> >>>>>> From my POV, the following things are important when choosing a >>>>>> “proper” MinGW-based compiler: >>>>>> >>>>>> - Prefer existing MinGW distros* over compiling& >>>>>> maintaining MinGW ourselves (although others may disagree here) >>>>>> - Make sure they are minimal and centered around C/C++ >>>>>> development (i.e. no elaborate gjc cruft like we still have in our >>>>>> current MinGW 4.4 packages) >>>>>> - Make sure we pick a distro that provides regular updates and >>>>>> provides new GCC versions in a timely manner >>>>>> - Let’s ship both a 64 and a 32 bit version, and ideally ones >>>>>> that provide a cross-compiler respectively >>>>>> - Let’s make sure we start providing them at the same time, and >>>>>> we start building our products with them >>>>>> >>>>>> Marius found http://sourceforge.net/projects/mingwbuilds/files/, which >>>>>> seems to satisfy all of the above. Other suggestions/preferences are >>>>>> welcome. >>>>>> >>>>>> If deemed necessary, we can also build our own MinGW distro via Qt >>>>>> Project’s public build infrastructure (http://builds.qt-project.org). We >>>>>> need good build recipes for that, though, and someone who is willing to >>>>>> maintain them. >>>>>> >>>>>> Cheers, >>>>>> Daniel >>>>>> >>>>>> *) by “Distro” I mean different entities compiling& providing MinGW >>>>>> releases such as MinGW.org, TDM, etc >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Why not wait till there is a MingW with GCC 4.7.0 release? I'm asking >>>>>> that since GCC 4.7 adds support for AVX and AMD bulldozer (bdver1) >>>>>> specific compiler optimization which seem to be greatly beneficial for >>>>>> AMD cpu's. So it might be worth the consideration to postpone the next >>>>>> Qt Creator release till there is a MingW with GCC 4.7.0. >>>>>> >>>>>> >>>>>> Just my opinion. >>>>>> >>>>>> >>>>>> Cheers, >>>>>> Mark >>>>>> _______________________________________________ >>>>>> Development mailing list >>>>>> Development@qt-project.org >>>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>> _______________________________________________ >>>>> Development mailing list >>>>> Development@qt-project.org >>>>> http://lists.qt-project.org/mailman/listinfo/development >>> _______________________________________________ >>> Development mailing list >>> Development@qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> _______________________________________________ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
