[Interest] Qt Binaries for Mingw 4.7

[Konrad Rosenbaum]

Hi,

On Monday 23 July 2012 04:24:48 K. Frank wrote:
> > 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/.)

;-)

> > 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?

Yes, I was able to confirm that it is 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.

Doubtful. The only way to do this would be to add buffering and prefetching to 
mingw implementations of read, write, open, close, etc. This would break some 
of the promises they make - i.e. that they are synchronous in regard to all 
other processes on the same machine.

But I could imagine that slipping a layer between mingw and gcc could help, 
since those promises don't need to be quite as strong in the typical GCC 
scenario (it is enough to be synchronized after the gcc process ends).

Hmm, is there an equivalent to LD_PRELOAD on Windows? I.e. is it possible to 
exchange certain library calls for some processes, but not others?

> 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.)

This introduces other problems: like getting Qt cross-compiled in the first 
place. I used to do this a few years ago, but gave up, since I only rarely 
compile on windows...


> 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.)

Out of curiosity: how much memory did it take? I usually give my Windows-VM 
less than 1GB.

> > 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?

Both by now. 

And the crash turned out to be a mistake I made while attempting to be 
portable between Qt4 and Qt5.



	Konrad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120723/f160867e/attachment.sig>