Does this error happen while configuring Slicer or CTK ?

Is there a "virtual box file" that I could use to reproduce and debug on my side ?

Unfortunately I don't have a virtual box available.

But if you have a PC with an external harddrive (or lots of RAM ~20GB) you could start a Ubuntu 12.04 beta live CD and compile there. Ubuntu 12.04 should be very similar to Debian Testing.

I made a change to Slicer4-SuperBuild/CTK/CMake/ctkMacroCompilePythonScript.cmake

Extract python lib path

• message(STATUS "PYTHON_LIBRARY_PATH: ${PYTHON_LIBRARY_PATH} , PYTHON_LIBRARY: ${PYTHON_LIBRARY}")
  get_filename_component(PYTHON_LIBRARY_PATH ${PYTHON_LIBRARY} PATH)

This results in
-- Found PythonLibs: optimized;optimized;optimized;debug;optimized;debug;optimized;optimized;debug;optimized
-- PYTHON_LIBRARY_PATH: , PYTHON_LIBRARY: optimized;optimized;optimized;debug;optimized;debug;optimized;optimized;debug;optimized
CMake Error at CMake/ctkMacroCompilePythonScript.cmake:23 (get_filename_component):
get_filename_component unknown component optimized
Call Stack (most recent call first):
Libs/Scripting/Python/Core/Python/CMakeLists.txt:37 (ctkMacroCompilePythonScript)

For some weird reason it cannot find Slicer's python library.

I can explain the problem, and it seems clearly a bug in FindPythonLibs.cmake. But don't know the solution, nor can I understand why only debian testing sees this problem.

(1) find_package(PythonLibs) is called several times in different CTK scripts
(2) inside FindPythonLib.cmake, the variable PYTHON_LIBRARY and PYTHON_LIBRARIES are set. they are set as a string that contains both the debug and release versions: "optimized;library.so;debug;optimized.so". this is by design; this string is sent to target_link_libraries(), which is smart enough to understand a string of this form.
(3) the second time find_package(PythonLibs) is included, PYTHON_LIBRARY still has its old value. It is passed as an argument to select_library_configuration(), which is illegal because that function only works on plain library strings (like "library.so") instead of the complicated library strings.

I am seeing this on Debian Squeeze with CMake 2.8.7 installed from backports.

$ apt-show-versions cmake
cmake/squeeze-backports uptodate 2.8.7-4~bpo60+1

I guess this is either a bug in this version of CMake or the Debian packaging.

I just built CMake 2.8.8 from source and it fixed this issue.

Thanks for looking into the issue :)

Dominique, Greg> Could you confirm that building using CMake 2.8.8 solves the problem.

cmake 2.8.8 works for me.

Now I am fighting with the missing launcher, but this is another story.