April 28, 2012

neveralull neveralull
Lab Rat
17 posts

Can a QT desktop application compiled on and for 32-bit Windows XP run on a 64-bit Windows 7 machine?

 

I have a Qt desk console application that works just fine. It was created using QtCreator in the Qt SDK on my 32-bit WindowsXp computer. I am supposed to run it on a 64-bit Windows 7 machine that has access to a hardware device, drivers, and an API to call the drivers. I installed the Qt SDK on the Windows 7 computer, but it permanently hangs as soon as you bring it up. I noticed there were a lot of complicated ways to build the application on my 32-bit machine for a 64-bit machine, but my co-worker insists that any 32-bit application will run perfectly fine on a 64-bit machine. Just copy the executable and any DLLs required, and viola! So I added CONFIG += static to my pro file, copied over missing DLL’s, and viola, it worked! But when I added in the hardware API, it kept crashing. I added a whole bunch of qDebug() statements, and once I did that, it no longer crashes. Everything, including the hardware, runs fine. But if I remove even a single qDebug() call, the whole program crashes. I don’t want to spend any more time debugging my program if the problem is Qt is not going to run on a 64-bit machine if compiled for a 32-bit machine. Can somebody please tell me if I am wasting my time, and if so, what should I tell my co-worker? Otherwise, I have a huge debugging problem ahead of me. And why does the Qt SDK hang as soon as you open it on my Windows 7 computer?

3 replies

April 28, 2012

Daniel Eder Daniel Eder
Lab Rat
58 posts

I see multiple questions at once in this thread.

From my personal experience and knowledge I can ensure you that there’s usually no problem to deploy and run 32bit applications to 64bit operating systems. Of course the 64bit OS needs to have 32bit support utilities and libraries installed, but if they are not that won’t usually lead to a crash but an according error message.

I see one point that could probably fit to the problems you are experiencing: You build your application on a 32bit OS using a 32bit driver API. If you deploy that application to an 64bit OS that provides only a 64bit API it won’t execute as a 32bit application may not access any 64bit libraries because they’re just not compatible. This also applies to Qt libraries – if you have them compiled as a 64bit on the target system you’re application won’t execute.

If you do a static build all these libraries are included in your binaries and hence there is no dynamic linking – and so no dynamic libraries are needed – hence you won’t run into any 32/64bit compatibility problems.

Why your application works with qDebug()? I don’t know. Maybe you’ve got a different configuration for Debug and Release builds where you add special libraries or something else that’s required in your Debug configuration but not your Release configuration.

I’ve got no idea why your Qt SDK (which part of it do you mean?) hangs – seems to be an installation issue. I’ve got it up and running in multiple OS including Windoes 7 64bit.

May 1, 2012

neveralull neveralull
Lab Rat
17 posts

Thanks for your reply. Here’s some more information. I have a class H with member functions A and B. H::A calls H::B concurrently via QFuture. Then A brings up a QTimer, and also a QProgressDialog, with a delay before the QProgressBar is shown. In the meantime H::B calls a function from the driver API, using a function pointer obtained from a previous QLibrary resolve() call. Since H::A and H::B are both member functions of class H, the attributes of class H should be available to both functions A and B, but what happens when the QProgressDialog starts running. Does it overwrite memory where class H’s attributes are stored, while H::B is still running concurrently in a thread obtained from the thread pool? If so, there would be no point in allowing class member functions to run via QFuture. And what about the memory that the DLL is using? Can that be wiped out by the QProgressDialog? Maybe since it is in a DLL, Qt doesn’t preserve it.

I can’t debug under these circumstances (not being able to compile on the target machine). What is happening with the installation is:
QtSDK comes up with the welcome screen, and any user input of any kind, pushing a button, or File menu for examaple, the screen grays out and hangs forever. This target machine has no access to the internet, if that could affect anything.

Any ideas?

May 3, 2012

neveralull neveralull
Lab Rat
17 posts

I was able to get QtCreator to run on the target machine, simply by hooking up an internet cable to it. I don’t know why. So now I can build my application on the target machine. It works fine as long as I build in Debug mode, but in Release mode, it fails – exactly the same way. I have opened up a new thread for this specific problem.

 
  ‹‹ [Moved] Template error      How to avoid type comparision using polymorphism ››

You must log in to post a reply. Not a member yet? Register here!