Re: [Interest] Qt Binaries for Mingw 4.7
Hi, On Monday 23 July 2012 23:24:38 K. Frank wrote: On Mon, Jul 23, 2012 at 4:33 PM, Konrad Rosenbaum kon...@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 signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Binaries for Mingw 4.7
On terça-feira, 24 de julho de 2012 09.06.36, Konrad Rosenbaum wrote: 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). While the preprocessor still exists as a separate executable, the preprocessing is not a separate step anymore. You can confirm that by adding -v to the gcc build and you'll see that it does not run cpp anymore. In other words, the compiler will do the preprocessing step. Moreover, in order to do optimisations, it needs to know the entire preprocessed output, but I'd guess it does so in an AST form already. The output from the compiler does jump between sections. But the output from the assembler doesn't, so the assembler needs to read the entire compiler output into memory before it can start writing out its own output. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Binaries for Mingw 4.7
Hi Konrad! On Tue, Jul 24, 2012 at 3:06 AM, Konrad Rosenbaum kon...@silmor.de wrote: Hi, On Monday 23 July 2012 23:24:38 K. Frank wrote: On Mon, Jul 23, 2012 at 4:33 PM, Konrad Rosenbaum kon...@silmor.de wrote: ... ... 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? ;-) No. Maybe it's a little selfish of me, but mingw / mingw-w64 is good enough for me, even if it is slow on bigger projects. (Also, I'm not sure that I'd have the strength to tackle something like this.) ... 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. If you do build Qt again with mingw and happen to get further information on how much memory is required, please consider posting what you learn. I'd certainly be interested. Which part of the build used the most memory would also be nice to know. (In my case linking QtGuid4.dll was the sticking point.) ... Konrad Thanks. K. Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Binaries for Mingw 4.7
Hello Thiago! On Tue, Jul 24, 2012 at 7:11 AM, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 24 de julho de 2012 09.06.36, Konrad Rosenbaum wrote: 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). While the preprocessor still exists as a separate executable, the preprocessing is not a separate step anymore. You can confirm that by adding -v to the gcc build and you'll see that it does not run cpp anymore. In other words, the compiler will do the preprocessing step. Moreover, in order to do optimisations, it needs to know the entire preprocessed output, but I'd guess it does so in an AST form already. The output from the compiler does jump between sections. But the output from the assembler doesn't, so the assembler needs to read the entire compiler output into memory before it can start writing out its own output. Thanks, that's helpful information to mull over. In terms of compiler speed, it seems to me that the consensus is that gcc on windows (e.g., mingw or mingw-w64) is slow. Would you have any thoughts on why that might be? I've heard a couple of different possibilities: one is that the cost of spawning processes is higher on windows; and now from Konrad that a lot of small i/o operations could be the culprit. ... Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Thanks for any further thoughts. K. Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Binaries for Mingw 4.7
Hi Thiago! On Tue, Jul 24, 2012 at 5:20 PM, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 24 de julho de 2012 11.04.22, K. Frank wrote: In terms of compiler speed, it seems to me that the consensus is that gcc on windows (e.g., mingw or mingw-w64) is slow. Would you have any thoughts on why that might be? I've heard a couple of different possibilities: one is that the cost of spawning processes is higher on windows; and now from Konrad that a lot of small i/o operations could be the culprit. Another possibility is that the malloc() is slow. There are many reasons why the same compiler in a different OS might be slow. Thanks Thiago. More food for thought ... ... Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Happy Hacking! K. Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Binaries for Mingw 4.7
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 signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Binaries for Mingw 4.7
Hello Konrad! On Mon, Jul 23, 2012 at 4:33 PM, Konrad Rosenbaum kon...@silmor.de wrote: Hi, ... 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. Well, that's good. (Sometimes effort pays off.) ... 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.) 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. ... 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.) 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, 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. ... Konrad Happy Qt Hacking! K. Frank ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Binaries for Mingw 4.7
Hi, On Thursday 19 July 2012, K. Frank wrote: On Thu, Jul 19, 2012 at 4:07 AM, Konrad Rosenbaum kon...@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). in my projects, which is fine for Linux, but there are some problems on Windows. 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... ;-) Moving back to an earlier GCC is not an option - I'd rather drop Windows- Support (I've already dropped Mac for the same reason). 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. (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. Windows runs in a VirtualBox VM, Guest Utils are installed, the sources and Mingw are in a shared folder. I would try to move everything to a virtual hard disk next - does anyone know whether this would help? 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). 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. 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). Konrad signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Binaries for Mingw 4.7
Hi Konrad! On Sun, Jul 22, 2012 at 11:38 AM, Konrad Rosenbaum kon...@silmor.de wrote: Hi, On Thursday 19 July 2012, K. Frank wrote: On Thu, Jul 19, 2012 at 4:07 AM, Konrad Rosenbaum kon...@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
Re: [Interest] Qt Binaries for Mingw 4.7
Hello Konrad, Le 19/07/2012 10:07, Konrad Rosenbaum a écrit : Does anyone provide a complete binary package for Qt 4.8.2 compiled with Mingw4.7? Are you trying 32bits or 64bits builds? The only really working 64bits MinGW I ever found is the one from TDM (http://tdm-gcc.tdragon.net/, also probably the easiest to install), but for now, no 4.7.x release available... Are you using MinGW-w64? Is is usable without MSYS, and installable without too much troubles? I'd be more than glad to try such a build, targetting 64bits binaries. Regards, -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Binaries for Mingw 4.7
I'm using MinGW with GCC 4.7.1 got from http://sourceforge.net/projects/mingwbuilds/, it works fine for Qt 4.8.1 and Qt 4.8.2. On Thu, Jul 19, 2012 at 4:07 PM, Konrad Rosenbaum kon...@silmor.de wrote: Hi, I'm using features of C++11 (provided by GCC 4.7, and maybe LLVM 3.1) in my projects, which is fine for Linux, but there are some problems on Windows. Moving back to an earlier GCC is not an option - I'd rather drop Windows- Support (I've already dropped Mac for the same reason). 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'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? Windows runs in a VirtualBox VM, Guest Utils are installed, the sources and Mingw are in a shared folder. I would try to move everything to a virtual hard disk next - does anyone know whether this would help? Any hints on how I could solve my dilemma? Does anyone provide a complete binary package for Qt 4.8.2 compiled with Mingw4.7? Konrad ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest -- Regards, Fan Yang ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
