XuvTools is developed in a cooperative effort from:
  • Chair of Pattern Recognition and Image Processing [www]
  • Friedrich Miescher Institute for Biomedical Research [www]
  • Center for Biological Systems Analysis [www]
 

This is an old revision of the document!


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.

Visual Studio Intel Compiler: "qmake project is in a zombie state"

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
boost library naming scheme

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
static versus dynamic linkage

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 statically linking QT, it can't use plugins (no jpeg, mng, and others)
  • when dynamically linking QT, it needs all system-libraries available at compile-time. Since QT links against libpng, which is compiled using qmake, that is a cat-tail-problem.
devel/collection_development_problems.1286403311.txt.gz · Last modified: 2010/10/07 00:15 by mario
Contact: admin(a)xuvtools.org