Building Qt on 64bit Windows: "conversion from 'size_t' to 'int', possible loss of data"
I'm trying to build 64bit QtCore4.dll on Windows 7 using Visual Studio 2010. I have some experience developing on Linux, but I've never done it on Windows, so I'm kind of running blind here and proceed based on fragments of information I find on various websites... So I did this: I fired up "Visual Studio x64 Win64 Command Prompt (2010)", navigated to the Qt source directory, from where I typed: "configure -fast -release" followed by "nmake". It seemed to work, but I noticed a lot of the mentioned warnings like this one:
../src/corelib/tools/qvector.h(296) : warning C4267: 'argument' : conversion fro
m 'size_t' to 'int', possible loss of data
core../../src/corelib/tools/qvector.h(296) : while compiling class template mem
ber function 'QVector<T> QVector<T>::fromStdVector(const std::vector<_Ty> &)'
core../../src/corelib/tools/qvector.h(796) : see reference to class template in
stantiation 'QVector<T>' being compiled
When I tried using the resulting lib, I got a lot of random crashes.
Any thoughts how to solve this? Or maybe someone can send me or point me to a 64bit QtCore.dll (from Qt 4.7)?
Thanks in advance for any help.
I have compiled Qt on Windows XP x64, and use it in my project without these crashes you mention. The size_t to int warning is quite common and mostly harmless. Maybe you could trace the reason of the crash?
I forgot to add, we use Visual Studio 2005, with the QMAKESPEC "win32-msvc2005" (The same is used for 64 bit too). Maybe you could try giving the appropriate makespec argument to configure, since you use Visual Studio 2010.
Well, it's either the way I build Qt, or the way I build my library on Windows, because it works like a charm on 64bit linux.
I tried debugging it in visual studio, but I couldn't figure out how to set it up to break on a crash. I can't even tell what type of crash it is exactly... When I'm debugging on linux using QtCreator it just stops when there's a segfault or other type of crash. VS on the other hand does nothing and lets the app die. How can I set VS to stop the execution on a crash?
bq. Maybe you could try giving the appropriate makespec argument to configure, since you use Visual Studio 2010.
configure.exe properly deafulted to win32-msvc2010, so there's no problem here.
As jim_kaiser stated already the warnings are frequently and typically harmless, but you should have made the same experience on linux anyhow.
Maybe you try it without the -fast and -release switches in your configure command.
bq. the warnings are frequently and typically harmless
Yeah, I didn't really think this through. I must have somehow associated size_t with pointers and thought there are pointers being butchered because some part of the buildsystem thinks it's compiling for x86. That was the best lead I had anyway
bq. but you should have made the same experience on linux anyhow.
Well, I just did a build on 64bit linux and there are no such warnings here.
bq. Maybe you try it without the -fast and -release switches in your configure command.
I'll try it tomorrow and report on the results.
bq. VS on the other hand does nothing and lets the app die. How can I set VS to stop the execution on a crash?
Generally, that shouldn't happen. Unless, you're building in release mode, it should break after a crash. You're saying you get no message at all? What about the execution output in Visual Studio, anything useful there? Also, I hope the command prompt is of x64 and not win64, you could explicitly set the environment by calling the appropriate .bat file (something like vcvars_x64.bat) or run vcvarsall.bat with the x64 argument.
I have to admit that I did not pay a lot of attention to warnings last time I had built it on linux. As long as it does not stop with an error, it seems to be fine ;-)
bq. As long as it does not stop with an error, it seems to be fine ;-)
That's a good rule of thumb, but here I was extra wary because I didn't really know what I was doing ;)
Allright, it seems I'm an idiot after all. I was so sure, that I was doing something wrong with building Qt, I didn't bother to check the one tiny part of code (just 3 lines) I changed when switching to Windows, which caused a bug I had in the code from the beginning to surface. So, sorry for all the fuss ;)
Sh.. happens. Good to know that you managed to get it solved.