[Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK

Fri Apr 20 13:53:50 CEST 2012

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-olsen at 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-olsen at 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-olsen at 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.molkentin at 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 at qt-project.org
>>>>>> http://lists.qt-project.org/mailman/listinfo/development
>>>>> _______________________________________________
>>>>> Development mailing list
>>>>> Development at qt-project.org
>>>>> http://lists.qt-project.org/mailman/listinfo/development
>>> _______________________________________________
>>> Development mailing list
>>> Development at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
>
>