[Interest] Qt Binaries for Mingw 4.7

[Konrad Rosenbaum]

Hi,

On Monday 23 July 2012 23:24:38 K. Frank wrote:
> On Mon, Jul 23, 2012 at 4:33 PM, Konrad Rosenbaum <konrad at silmor.de> wrote:
> > ...
> > 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.
> 
> Well, that's too bad.  I wonder how microsoft does it.  (My
> understanding is that the msvc compile times are pretty good.)

My guess would be: start a thread per source file, map the entire pre-
processed source into memory, generate the object file in memory, and finally 
write the object file out in one go, end the thread.

As compared to most other compilers: keep each compile step in one process 
(pre-processor, compiler, assembler makes at least 3), read files as you go, 
pipe them from one process to the next, reading as many bytes as you need for 
the next step, write out the results as they come along (one function at a 
time, jumping between different sections of the object file too).

> > 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?
> 
> Thanks for the suggestions.

Do I take it you have a plan? ;-)

> > ...
> > 
> >> 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.
> 
> I don't know exactly.  I would say that I needed pretty close to 2 GB
> (not just for the linking process itself, but also for whatever else the
> os felt it needed.)

Ok, I definitely need to increase my VM size when building Qt.

> My reasoning is that I have 2 GB of physical memory.  I tired the
> build after my machine had been running for a while, and with some
> irrelevant processes running, and the build failed.  I then rebooted,
> and killed of what I thought were extraneous processes, and the
> build succeeded.
> 
> If I had to guess, I would guess that the build needed somewhere
> between 1.5 and 2 GB, but that's just a soft guess.
> 
> I don't know to what extent the memory you assign your VM and
> the physical memory on my machine are comparable,

In theory it should be pretty much comparable - from the point of view of the 
VM it has physical memory. The only differences it sees is that the chipset 
was manufactured by VirtualBox, it has some weird drivers for those "chips", 
and the CPU-counter and clock tend to jump a lot. Memory wise it believes it 
works with physical RAM and physical hard disks, although both are virtual.

> and I don't
> know what effects my using 64-it windows has, but based on my
> experience, I'm not surprised that your build failed with out of memory
> if you gave it less than 1 GB.

My guess would be a factor or 1.1 - 2 depending on the application, the more 
it handles pointers the closer it gets to 2.



	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/20120724/f08f71de/attachment.sig>