[Development] Choosing a new MinGW for Qt 5
Loaden
loaden at gmail.com
Thu Aug 30 17:05:03 CEST 2012
I want to say, mingw-w64 is the best choice.
I am using ruben's personally build to compilation Qt5/QtCreator on both
Windows and Linux OS, and it works well!
2012/8/30 <kai.koehne at nokia.com>
> Hi,
>
> I'd like to get this on the table again: What is the MinGW package that we
> want to support officially? The matrix for Qt 5.0 right now says MinGW gcc
> 4.5 32 bit [1]. Note that when you're installing latest mingw from
> mingw.org it's already installing gcc 4.7, and I guess you'd need to dig
> into the archive to get gcc 4.5 ... But anyway, it's still 32 bit only.
>
> In the last days I gave the following packages that also support both 32
> bit and 64 bit a try:
>
> TDM-GCC: Nice installer, but somewhat stale (gcc 4.6.1 / gdb 7.3.1) + not
> much (visible) activity
> Mingw-64: last official 1.0 build is from a year ago (gcc 4.5.4). There
> are popular, 'semi-official' personal builds with 4.7.1 though ...
> Mingw-builds: gcc-4.7.1, gdb 7.4.1. packages for gcc-7.4.2 are already in
> the prerelease directory ...
>
> One might think that the only difference in these packages is the gcc
> version, but this isn't the truth. They also deviate e.g. in the COM
> headers, which can easily lead to build breakages ... That's why I think
> it's important to promote _one_ mingw 64 bit package as the officially
> supported one, and ideally even get it CI tested.
>
> After trying all, I agree with Marius that mingw-builds seems a good
> choice. Qt 5 beta compiled out of the box for me with one minor patch [3]
> ...
>
> So, I think we have a couple of choices here:
>
> * We could just add mingw-builds gcc 4.7.1 64 bit to the list of tier 1
> configurations, keeping mingw gcc 4.5 32 bit as reference platform.
> + no changes after beta for reference platforms
> - two different compilers are more work to test
> * We could try to make both mingw-builds gcc 4.7.1 64 bit and 32 bit a
> tier one platform, and get rid of the Mingw from http://www.mingw.org/
> + The same toolchain can be tested for 32 bit and 64 bit
> - 5.0 beta is already out
> - gcc from mingw.org is probably more wide spread/better tested than
> mingw-builds
> * We could leave it as it is, with no recent mingw compiler to easily
> install, and no 64 bit one
>
> Opinions? Note that at the moment we don't test MinGW at all in the CI
> system [2].
>
> Regards
>
> Kai
>
> [1]: Official platform matrix:
> http://qt-project.org/wiki/Qt_5.0#ed49a36c4fd547e5e2ace11bef4f21cf
> [2]: CI system needs to build with MinGW on Windows:
> https://bugreports.qt-project.org/browse/QTQAINFRA-549
> [3]: Codecs: Fix compilation on MinGW if configure detects iconv:
> https://codereview.qt-project.org/#change,33936
>
>
> > -----Original Message-----
> > From: development-bounces+kai.koehne=nokia.com at qt-project.org
> > [mailto:development-bounces+kai.koehne=nokia.com at qt-project.org] On
> > Behalf Of Storm-Olsen Marius (Nokia-MP/Austin)
> > Sent: Friday, April 20, 2012 1:54 PM
> > To: pgquiles at elpauer.org
> > Cc: development at qt-project.org
> > Subject: Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
> >
> > 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_Lin
> > ux_For_Windows_with_MinGW#Differences_between_mingw32_and_ming
> > w-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
> > >
> > >
> > >
> > _______________________________________________
> > 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
>
--
Best Regards
Yuchen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120830/486e1cd7/attachment.html>
More information about the Development
mailing list