Rubens release is currently broken, and there shouldn't be a need for a separate package for 32bit vs 64bit really.
-- .marius On 30/08/2012 10:05, ext Loaden wrote: > 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.koe...@nokia.com <mailto:kai.koe...@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 <http://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 <http://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....@qt-project.org > <mailto:nokia....@qt-project.org> > > [mailto:development-bounces+kai.koehne > <mailto:development-bounces%2Bkai.koehne>=nokia....@qt-project.org > <mailto:nokia....@qt-project.org>] On > > Behalf Of Storm-Olsen Marius (Nokia-MP/Austin) > > Sent: Friday, April 20, 2012 1:54 PM > > To: pgqui...@elpauer.org <mailto:pgqui...@elpauer.org> > > Cc: development@qt-project.org <mailto:development@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 <http://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 > <mailto: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_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 > <http://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 > <mailto: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/ <http://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 <mailto: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 > <mailto: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 <mailto:Development@qt-project.org> > > >>>>>> http://lists.qt-project.org/mailman/listinfo/development > > >>>>> _______________________________________________ > > >>>>> Development mailing list > > >>>>> Development@qt-project.org <mailto:Development@qt-project.org> > > >>>>> http://lists.qt-project.org/mailman/listinfo/development > > >>> _______________________________________________ > > >>> Development mailing list > > >>> Development@qt-project.org <mailto:Development@qt-project.org> > > >>> http://lists.qt-project.org/mailman/listinfo/development > > >> _______________________________________________ > > >> Development mailing list > > >> Development@qt-project.org <mailto:Development@qt-project.org> > > >> http://lists.qt-project.org/mailman/listinfo/development > > > > > > > > > > > _______________________________________________ > > Development mailing list > > Development@qt-project.org <mailto:Development@qt-project.org> > > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development@qt-project.org <mailto:Development@qt-project.org> > http://lists.qt-project.org/mailman/listinfo/development > > > > > -- > Best Regards > Yuchen > _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development