Re-Occuring Development Problems / Pitfalls

Several issues can arise when developing XuvTools. Here we collect common mistakes, unfixed thirdparty software errors, and other problems that are likely to arise.

When an application project contains a version number, the Intel project converter will generate an incorrect vsproj file. Visual Studio will show an error message saying “project is in a zombie state”. This error can be avoided by removing the version number from the application project. Here an example of a problematic qmake project file:

TEMPLATE = app
[...]
# The following line will cause MSVC Intel converter to fail:
VERSION = 1.0.0

The boost library has a clever concept of generating linker dependencies, that works the following: when including boost headers, they instruct the compiler to link against matching boost libraries. For this to work, boost libraries have a name that includes their compilation properties! Namely, this is the compiler toolkit name, the boost version, threading status, and whether its a debug library or not. See the following table for common examples. If the library name contains:

'mt'   - multithreaded library
'gd'   - debug library
'iw'   - compiled with toolkit Intel compiler
'vc90' - compiled with toolkit MSVC 9.0 (2008)
'vc100' - compiled with toolkit MSVC 10.0 (2010)

This system can be tricky to use with certain build tools! As an example: Jace depends on boost, but Jace is compiled with MSVC, whereas the libBlitzBioFormats that makes use of Jace is compiled with the Intel compiler - which leads to different boost library names - and therefore linking fails! But boost provides the following switches to change behavior of the library naming:

--layout=tagged    - Only 'mt' and 'gd' flags in library name. Example: libboost_thread-mt-gd.lib
--layout=system    - No flags in library name at all (can not build debug/release at the same time). Example: libboost_thread.lib
--layout=versioned - default: full flags in library name. Example: libboost_thread-vc90-mt-gd-1_44.lib

A commonly reoccuring topic is linkage: static versus dynamic. XuvTools links all libraries statically (except for JVM, which is not available statically). Here is a collection of facts to start with:

• mixing dynamic and static linkage is not a good idea. Each dynamic object will contain a copy of all static libs its linked against, so you can have a (different) libpng.a in every dll and the executable. What is worse: when throwing exceptions that are defined in static code, multiple instances exist, so the matching (=catching) might fail.
• when linking QT statically, some problems arise:
  • static linked QT can't use plugins (no jpeg, mng, and others)
  • on MacOS, one can not build x86_64 (Cocoa) QT statically
• when linking QT dynamically, several issues arise:
  • dynamic QT requires its dependency-libraries available at compile-time. Since QT links against libpng, which is compiled using qmake, that is a cat-tail-problem.
• dynamic linking on Windows is a big problem:
  • libraries need to export symbols, else the *.lib import library file is missing. E.g., libpng and zlib can not easily be compiled dynamically on Windows using the qmake-based build system!

QT requires to be compiled with (some) qt library enabled, else it will not be able to load the default icons (file browser etc.). If compiling QT 4.6.3 with -qt-libpng, it will still pick up the png.h from /usr/include, in case it is installed. This can lead to library confusion of the following form:

libpng warning: Application was compiled with png.h from libpng-1.2.40
libpng warning: Application  is  running with png.c from libpng-1.4.4