Static link with cmake under windows (Qt and others)
One of the great things about Qt is that you can compile the code under esoteric OSs (mmh?) like Windows or MacOS. Although I’ve almost never used windows, I did the packaging of yzis. I used the Nullsoft Installer, which is ok.
I had several issues with static linking, and thought maybe some of you could give some help about it. Don’t ask why I want static link, this is not the issue here.
Problem #1:
The most important one is Qt itself. I expected that to be easy, but it is not. The FindQt4 shipped with cmake 2.4.8 or 2.6 is not really aware of static lib, or is it ? Nor is the one from kde svn. I’ve tried using the one from quassel-irc, but it fails as well. If you can help me with this, the code is available.
It seems (according to #qt on irc) that it makes sense to have two different Qt installed, one static and one shared. I did that (double the space used…) and in one of them did “configure -static” and recompiled qt. Now the *.a are much bigger, and though qyzis links against those *.a, it still depends on the DLLs, according to “dependencies walker”. Gr…
Problem #2:
Then, there is the problem of gnuwin32 tools. In the lib/ directory, you can find for example
- libintl.dll.a
- libintl.def
- libintl.lib
And the DLL (libintl3.dll) is in the bin/ directory. I need to ship the DLL with qyzis, because cmake found the dll, and linked against libintl.dll.a. In a perfect world, I would like cmake to use the libintl.lib and have a static link, but i dont know how to convince cmake of doing that. Do you know ?
Problem #3:
How do you find out what kind of library a file is ? According to what I’ve found googling the web, libraries can have a wild number of different names (libX.dll, libX.dll.a, libX.lib, libX.a, all of this without the lib prefix and so on…). Even worse : libX.a for example, could be either a static lib or the stub for the DLL. Do you have clarifications about this ? Do you know of a reliable way to know which kind of library it is ? (DLL, DLL stub, or purely static).
Post details
- Categories: KDE
- Published: June 27, 2008
Sorry, can’t really help.
I’m no Windows expert, and I also never had to prefer static over shared libs.
Please ask on the cmake list or maybe on the kde-windows list.
Generally, the kde-buildsystem list is also a good place for such questions. There you can rely on that it will be read by the right people.
Alex
AFAIK, .dll.a = MinGW import library, .lib = M$VC import library. The GNUWin32 packages don’t include static libraries, you have to build them from source, and projects don’t always support them (especially on Window$ where DLLs and static libraries work quite differently).
Your first problem is on your side – it works perfectly here (kdewin-installer, speedcrunch packaging, …) There must be something wrong on your side. Make sure to not mix the static and shared libs when doing cmake configure (Take a look with cmakesetup which libs are used).
The second problem is properly explained by kevin kofler and the third one is a little bit complicated 🙂
You can’t distinguish between a static and a static import lib. On MinGW a static lib ends with .a, an import lib with .dll.a (when the packager follows this detail). Msvc static and static import lib both end with .lib. A shared lib ends always with .dll