PDA

View Full Version : [SOLVED] static linking with Qt4 and MinGW32 -- or something else?



lari
16th February 2006, 11:13
Hi,

I'm developing a program that, for the ease of use, I'd like to distribute as a staticly linked executable. The program is a Qt-interface to a command-line application and the critical part is calling (using threads) some C++ routines that I've written earlier. I've developed the stuff using SUSE 10.0 and it works fine on OSX, too. I have serious problems to get it running on Windows.

On all the three platforms, I've compiled Qt 4.1.0 with flag '-static'. Then setting QTDIR to point to the right place and typing qmake -project, qmake and make do the right job on Linux and OSX. On Linux, ldd shows that no Qt libs are dynamically linked:

linux-gate.so.1 => (0xffffe000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40032000)
libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0x4003a000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40043000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x400b1000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x400e1000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x400ef000)
libdl.so.2 => /lib/libdl.so.2 (0x401e9000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x401ed000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x401ff000)
libm.so.6 => /lib/tls/libm.so.6 (0x402db000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40301000)
libc.so.6 => /lib/tls/libc.so.6 (0x4030c000)
libz.so.1 => /lib/libz.so.1 (0x4042c000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4043f000)
/lib/ld-linux.so.2 (0x40000000)

The program runs fine on a different machine that doesn't have Qt 4 installed.

I'm not familiar with Windows but followed the instructions to set up the opensource Qt with MinGW32 and then to re-compile it with -static flag. In order to compile the application, I opened the Command Prompt from the Qt menu and typed qmake -project, qmake and mingw32-make. The code compiled fine and the application can be started but it then crashes soon (~30s) after calling the routines mentioned earlier. The program finishes with a popup window informing of a runtime error.

I though that the problem could be in (1) static linking, (2) threads/zlib or (3) STL. I don't know if the compilation/ linking of the application is done correctly and what kind of dependencies to expect in a normal case. The program 'depends' gives the following output (lower-level dependencies removed):

[ ] c:\some\path\to\here\src\bin\PROGRAM.EXE
[ ] c:\windows\system32\ADVAPI32.DLL
[ ] c:\windows\system32\COMDLG32.DLL
[ ] c:\windows\system32\GDI32.DLL
[ ] c:\windows\system32\IMM32.DLL
[ ] c:\windows\system32\KERNEL32.DLL
[ ] c:\some\path\to\here\src\bin\MINGWM10.DLL
[ ] c:\windows\system32\MSVCRT.DLL
[ ] c:\windows\system32\OLE32.DLL
[ ] c:\windows\system32\OLEAUT32.DLL
[ ] c:\windows\system32\SHELL32.DLL
[ ] c:\windows\system32\USER32.DLL
[ ] c:\windows\system32\WINMM.DLL
[ ] c:\windows\system32\WINSPOOL.DRV
[ ] c:\windows\system32\WS2_32.DLL

As expected, the executable and MINGWM10.DLL are there but then there are many Windows-specific dll's. Should they be there or is my code erroneously linked to some native stuff that could cause incompatibility? I suppose Qt needs something?

As the crash occurs in a computationally intensive part that is done in another thread and that part of code relies heavily on STL, I though zlib and STL could be related to the problem. I wonder if native/Qt/MinGW zlibs (defined in configuration) could make a difference or would it show differently? As MinGW is based on GCC, I wouldn't expect great differences between systems on STL if the linking is fine. I just wonder which STL qmake and mingw32 use -- or is it again a question of linking?

The problem is that I don't know much about Windows and can't even guess where things could go wrong. I do know that the application works fine on Linux/OSX (GCC 3.3.* or 4.*) and, according to valgrind, shouldn't be leaking. Do you have any suggestions how to minimize the risk of incompatibility of different compilers/ libraries/ STL or debug the code on Windows? Should I recompile Qt with different options or focus on my code and MinGW?

Thanks a lot in advance!

Rgds, Ari

wysota
16th February 2006, 13:00
Could we see the code which crashes your app?

lari
16th February 2006, 16:55
The whole thing is thousands of lines of code and there's no particular piece that I know to be causing the crash. Before it crashes, the GUI calls routines that run fine as a command line application (in a single thread) and now those routines proceed somewhere half way through.

I guess that it's very difficult to say anything without seeing the code but I hoped that there'd be someone who has had similar issues with opensource Qt, MinGW and static linking. Maybe it's not at all about linking but something to with threads -- or a stupid bug stupid bug that is ignored in Linux/OSX.

Ari

wysota
16th February 2006, 20:48
If you run your app under a debugger, you'll see exactly where the application crashes. Without it it's like looking for a needle in a haystack.

lari
20th February 2006, 10:11
Don't know what's wrong but compiling without optimisation ( -O0 ) seems to solve the problem.