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 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!
devel/collection_development_problems.1286486145.txt.gz · Last modified: 2010/10/07 23:15 by mario
Contact: admin(a)xuvtools.org