Posts Tagged ‘ Visual Studio ’

gtest + CMake + Visual Studio

I should have posted this sooner, but all kinds of things got in the way and… Okay, that was just some lame excuse, it is because my laziness that this site has been left unattended.

I suddenly felt the urge of writing this post because the other day I saw my friend Dat was trying to get gtest to work with Visual Studio but ended up getting cryptic messages from linking errors. This has happened to me before, and I have investigated this issue.

In fact, using gtest library with CMake is fairly easy and straightforward. All you need to do is to find the corresponding library and the include path, and then link the gtest library against the executable. This works without a problem in Linux. However, it becomes a bit tricky when used in Windows (as expected?).

The main issue is the Runtime Library setting in Visual Studio:

By default, it tries to load DLL, but I was feeding it LIB file. No wonder it complains. Suppose I am building in debug mode, I need to specify gtestd.lib to be my target library and select “Multi-threaded Debug (/MTd)” as the runtime library, whereas in release mode gtest.lib needs to be specified and “Multi-threaded (/MT)” should be selected.

So, is there any workarounds to avoid this manual hassle? Sure, simply do


in the CMakeLists.txt, and it will be set automatically (somehow I was under the impression that I have tested this before and it was not working, but it did work just now).

Of course, you can specifically indicate that you want a DLL to be built in gtest. Yet so far I haven’t found a way to utilize the DLL (such that it can work with /MD or /MDd), I would have to defer this problem to some C++ gurus, i.e. George Toderici (if Google Alert ever alerts him about the existence of this post), to answer.

Moving ahead doesn’t always gaurantee a superior position

OK, I admit it, I don’t really know why Visual Studio 2008 is better than 2005 and I am also aware of the fact that Windows Vista is running slower than Windows XP. I did the switch only for the sake of upgrade, as I have this unexplained compulsion to become up-to-date, and visual satisfaction from the inherent fanciness of the successors.

The consequence, as one might expect, is possible negative impact on productivity. Although I was lucky to finally have workarounds (by workaround I don’t mean reinstalling the compatible version) for the projects I am actually involved in, the time spent to search for solutions is substantial.

From what I have experienced so far, there are three scenarios in which using VS2008 and Vista could be annoying.

  1. Before the recent release of Qt 4.4, VS 2008 was not officially supported by Qt 4.3. This basically means that you might be able to use Qt 4.3 without a problem, yet on the other hand it could have driven you crazy after you spent hours to debug only to find it to be a compatibility issue (I started using 4.4 when it was still a snapshot so I only speculated what would happend). This usually causes the mildest annoyance as you might not run into problems at all.
  2. Before the recent release of MySQL 5.0.51b, it had some known bugs when installed on Vista (as well as on Leopard). What makes this scenario better than the last one is that you have workarounds (thanks to Google), and at the same time a newer version often tends to be released soon and fix the bug. Another example is Warcraft III, which started to run properly on Vista after applying the latest patch.
  3. Last but perhaps the most disturbing thing, is having to wait for the software/SDK to have support for VS 2008 without any specific time frame, as in “we currently don’t have plan to support Visual Studio 2008”. CUDA, for instance, does not support Vista until the latest release of 2.0 beta. To make it even worse, this version of toolkit does not work in VS 2008. Fortunately I only wanted to play around with it.

I was actually quite surprised by these incompatibility issues since Vista has been out for two years already. Yet apparently some software developers are more rational than I do. Thus in cases when the Vista-incompatible libraries and/or applications are mission-critical, unless you find a fix and meanwhile is willing to go through the trouble, stick with VS 2005 and/or XP.

Qt 4 + CMake + Visual Studio rules now

Thanks to Bill from Kitware Inc., who responded my previous post in a very timely manner and helped me solve the compilation issues as well as the execution error.  CMake and Visual Studio 2008 are now back in the triangle.

The compilation problem lies the source code of the Qt demo. Two other classes were declared in two of the class definition .cpp files so that either moc’ing the sources or moc’ing the headers will leave some of Q_OBJECT classes un-moc’ed, which causes the linking errors. On the other hand, qmake handles this implicitly so the project file it generates doesn’t have this problem. After moving those declarations to the header files, everything compiled nicely and quietly.

As for the debug execution problem, Bill also suggested that the commercial evaluation version of Qt 4 binary I downloaded might be built with VS 2005. If that is the case, there is no way I can execute in debug mode the program linked against the Qt 4 libraries. I was just being so naive to make the assumption that the binaries should be of no difference if QMAKESPEC is the same.

After downloading and compiling the source of Qt 4.4 beta (boy, that compilation DID take QUITE a while), everything went back to normal. I am now happily “CMaking” my projects again.

Qt 4.3.4 + CMake + Visual Studio 2008 doesn’t work

Hoping to create a nice GUI for the project I am currently working on, I downloaded the commercial version of Qt 4.3.4. It installed fine, with the option of integrating with Visual Studio disabled since the integration with VS 2008 is not officially supported yet. Trolltech has already announced to support this in the upcoming version of 4.4, though.

The demo that comes with the package looks really appealing, just like how I like it: simple, themed design and fluent animated transition, which together provide the user with maximum visual satisfaction.

Trolltech is generous enough to have included all the source code of the demo so that we can play around and figure out how to mimic those fancy effects. At first I planned to use CMake to generate the project file (.sln file in the case of Visual Studio) for the demo, in accordance with all other projects that I am working on. There are also examples of CMakeLists.txt for Qt 4 projects (here is one). Despite it seemed that everything should be easily done without any hustle, it soon turned out not to be the case this time.

First, the solution file generated by CMake just won’t compile (unless it’s a single main.cpp, in which case I got it to work) if there are other Q_OBJECT classes present. I tried both QT4_AUTOMOC and QT4_WRAP_CPP, all ended up with “error LNK2019: unresolved external symbol“:

SET(SRCS src/main.cpp src/mainwindow.cpp)
SET(HDRS include/mainwindow.h)

and either




Correct me if I am doing anything wrong above. After googling a bit I figured that something is wrong with the moc’ing process, but I haven’t yet found a solution. Thus I am taking CMake out of the equation temporarily.

A nice thing about qmake that comes with the Qt package is that just like CMake it can generate project files for different platforms, with an equivalent of CMakeLists.txt, file. With the command

qmake -tp vc -spec win32-msvc2005

one can easily get the project file (.vcproj/.sln) for Visual Studio 2005 to use. The project compiled under VS 2008 without any error, but when running under debug mode I get either “This application has failed to start because the application configuration is incorrect” if the solution file is generated by qmake or “The application failed to initialize properly (0xc0150002)” if it is created by CMake (remember I had one single main.cpp compiled). However, the release builds executed correctly.

Again I googled for a while and found out the problem might lie in the manifest files of the Qt core dll’s. Since the QMAKESPEC is set to win32-msvc2005, the manifest files of the dll’s have VS 2005 info (Microsoft.VC80.DebugCRT) embedded. When the program compiled with VS 2008 (VC90) and linked against those dll’s tries execute, there’s a conflict in configuration. Unfortunately, none of the solutions I found worked.

Now it is quite clear that for now I cannot (at least easily) debug the Qt4 programs in VS 2008. VS 2005, on the other hand, is working as advertised both in debug and release mode. Guess I would have to stick with VS 2005 for a while before Qt 4.4 is released.

An alternative plan would be trying out the 4.4 beta to see if it is a solution, while using qmake to generate the Makefile, from which to see how the CMakeLists.txt should be written.