[Interest] Qt Binaries for Mingw 4.7

[K. Frank]

Hi Konrad!

On Sun, Jul 22, 2012 at 11:38 AM, Konrad Rosenbaum <konrad at silmor.de> wrote:
> Hi,
>
> On Thursday 19 July 2012, K. Frank wrote:
>> On Thu, Jul 19, 2012 at 4:07 AM, Konrad Rosenbaum <konrad at silmor.de>
> wrote:
>> > I'm using features of C++11 (provided by GCC 4.7, and maybe LLVM 3.1)
>>
>> Me too, especially std::thread.
>
> Lambdas and variadic templates (in connection they make a nice wrapper for
> directing signals to lambdas with an unchanged Qt4).

Yes, good point.

(As presumably you know, one of the c++11 features supposedly
supported by Qt 5 is lambdas for slots.)

>> I have been using mingw-w64 4.7.0 with Qt to good effect.
>
> Ok, I did not move Windows to 64bits yet. With Windows I'm always afraid
> that the Redmonders mix up 8-byte-wide addresses with drinking 64 Bit beers
> (short for Bitburger beer) - that much would definitely not be good for
> you... ;-)

Yes, that could be a problem.  (You've heard of Windows ME, of course.
See, for example, http://xkcd.com/323/.)

>> > ...
>> > If I use the official Qt 4.8.2 binary package for Mingw 4.4 the
>> > application crashes immediately on start when it is trying to
>> > initialize itself. I presume a Qt compiled with Mingw4.4 is
>> > incompatible with a project compiled with Mingw 4.7 - is this correct?
>>
>> I do not know for sure, but it would not surprise me if 4.4 and 4.7
>> code would be incompatible.  The various mingw projects do try
>> to maintain abi (link-time) compatibility, but not at all costs.  I have
>> always been conservative and made a point of rebuilding Qt (and
>> other libraries) when upgrading the version of g++ I use for day-to-day
>> use.
>
> The version of the main library for MinGW changed from 3.16 to 3.17 between
> 4.6 and 4.7 - this might indicat an ABI break. :-(
>
>> > I'm also trying to compile Qt myself - after several days it is still
>> > in the middle of compiling the Webkit module. I know compiling on
>> > windows is slow - but this bad?
>>
>> My most recent build of Qt was 4.8.0-rc1 (so not your 4.8.2 version,
>> but still 4.8) using a 64-bit mingw-w64 Ruben personal build of
>> g++ 4.7.0 on a native 64-bit windows 7 system.
>>
>> It took "about a day" (where "about a day" might mean, say, ten
>> hours).  It was certainly "rather slow" -- it didn't take just a couple
>> of hours, but neither did it take a couple of days.
>
> I could reduce to 5 hours by moving the sources from my "shared drive" to a
> virtual hard disk and by configuring Qt to not compile Webkit and all
> Multimedia related modules.

Do I take it correctly that you've managed a g++ 4.7 windows build
(i.e., mingw) of Qt?  Is it working?

>
>> (As I understand it, make / g++, with their roots in the unix world,
>> spawn a bunch of subprocesses to do the work, and that's an
>> expensive process on windows.)
>
> I'm getting the feeling that GCC and especially ld make a lot of separate
> and small file I/O operations - these come at almost no cost on Unices, but
> bear a heavy cost on Windows. A few years ago I found out the hard way that
> regular fflush-calls make a runtime-difference of factor(!!) 60 between
> Linux and Windows - it seems things are even worse on networked file
> systems.

That's very helpful to know.  I wonder if that could suggest a way to
speed up mingw.  I kind of doubt the the upstream g++ would be
particularly supportive of significant changes that would help windows
performance -- but you never know -- but perhaps there is something
that could be done purely on the mingw end of things.

I compile natively, but my understanding is that a lot of people who
use mingw to build windows applications use a linux-hosted mingw
cross-compiler, in part because of the slow compile times on windows.
(Maybe that could be a solution to your problem.)

>> > ...
>> I definitely have had link times be really slow when the input
>> object files and the output exe's and/or libs resided on network
>> storage, rather than on a local hard drive.
>>
>> I don't know whether this is relevant to your case, though.
>
> It seems to be.
>
>> One comment:  I built Qt using its "default" configuration (i.e.,
>> I didn't explicitly turn anything on or off).  I think that Webkit
>> gets built by default, but I don't actually know.  (I'd be glad
>> to check if someone would tell me how.)
>
> It does get built by default - that what took about 2 days before it crashed
> the build-process while linking (memory exhausted in ld).

I should note that when I upgraded to g++ 4.7.0 and Qt 4.8.0-rc1,
I almost didn't have enough memory to complete the build.  The
build process ran out of memory when linking QtGuid4.dll, but
after a fresh reboot and killing off what I deemed to be some
unnecessary processes (to free up as much memory as I could),
I was able to rerun the build process and have it complete successfully.

(At that time people made various suggestions as how to reduce
the memory requirements of the build.  But since I ended up having
enough memory, I didn't try any of them, and I did successfully
complete the default build.)

>> Also, I did not use the g++ command-line argument that turns
>> on c++11 support ("-std=c++0x") when compiling Qt.  I believe,
>> but haven't verified, that I could compile my code with -std=c++0x,
>> and link it with Qt built without.
>
> It's certainly possible on Linux and I did do this on Windows while I was
> still using GCC 4.6.2 and Qt 4.7.4.

Thanks, good to know.

> With GCC 4.7 and Qt 4.8.2 I just compiled Qt without any -std=* flag and the
> program with -std=g++0x. It runs, but crashes on a very specific operation -
> I'm still investigating why (might be OpenSSL or a flaw in my program).

Do I assume correctly that this is on linux, or do you mean that you
have your windows build working?

>         Konrad

Good luck.


K. Frank