June 27, 2008

Static link with cmake under windows (Qt and others)

by orzel
Categories: KDE
Tags: , , , ,
Comments: 3 Comments

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).


  1. Alexander Neundorf says:

    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.


  2. Kevin Kofler says:

    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).

  3. 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

Leave a Reply

Your email address will not be published. Required fields are marked *