uploaded complete log file

After investigating it resumes an test executable fails to link. (qSlicerDataModuleWidgetsCxxTests)

Compiling using:

make -j4 -k

should build all targets possible ignoring error and will allow you to work and fix bugs related to EMSegment.

We will investigate further on our side.

it still does not compile without error

[ 59%] Built target qSlicerDataModuleWidgetsPythonQt
Linking CXX executable ../../../../../bin/qSlicerDataModuleWidgetsCxxTests
/software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyType_IsSubtype' /software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyErr_GivenExceptionMatches'
/software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyNumber_Power' /software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyExc_RuntimeError'
/software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyString_Size' /software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyErr_Print'
/software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyString_FromStringAndSize' /software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyBaseObject_Type'
/software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyDict_Keys' [...] /software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyDict_New'
/software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyGILState_Release' /software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPySequence_GetItem'
/software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyObject_GetItem' /software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPy_BuildValue'
/software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyNumber_Float' /software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyNumber_Rshift'
/software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyFloat_Type' /software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyDict_Update'
/software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyObject_HashNotImplemented' /software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyLong_FromUnsignedLong'
/software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyEval_CallObjectWithKeywords' /software/Slicer4/superbuild/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyTuple_Size'
collect2: ld returned 1 exit status
make[2]: [bin/qSlicerDataModuleWidgetsCxxTests] Error 1
make[2]: Target `Modules/Loadable/Data/Widgets/Testing/CMakeFiles/qSlicerDataModuleWidgetsCxxTests.dir/build' not remade because of errors.
make[1]: [Modules/Loadable/Data/Widgets/Testing/CMakeFiles/qSlicerDataModuleWidgetsCxxTests.dir/all] Error 2
[ 59%] Built target qSlicerDataModuleWidgetsPlugins

...
[100%] Built target MultiVolumeExplorerCxxTests
make[1]: Target Modules/Loadable/all' not remade because of errors. make: *** [all] Error 2 make: Targetdefault_target' not remade because of errors.

That is expected. Using "-k" allow to push the compilation to the end without stopping because of the error related to the "test executable".

You can know run Slicer and build targets specific to EMSegment.

This should allow you to work and fix bug related to EMSegment.

As mentioned, we are investigating the error.

COMP: Update VTK tag to use a Slicer VTK fork based on v.5.10.0
See http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=20627

Please, after updating your Slicer checkout and rebuilding, let me know if the link problem is still present.

yes it is

Just to make sure, could you confirm that you did a build from the top level directory ?

yes I build from the superbuild directory

Issue seems to be specific to newer version of gcc, an email have been sent to the kitware developer internal list to obtain feedback:

// -------------------------------------------
Hi Folks,

I am facing a link error that I can't manage to track down. I would appreciate your input.

VTK version: v5.10.0 + 2 custom commit. See https://github.com/Slicer/VTK/commits/slicer-4.1-v5.10.0

The command reported below gives me the following error:

<SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyType_IsSubtype' <SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyErr_GivenExceptionMatches'
<SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyNumber_Power' <SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyExc_RuntimeError'
<SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyString_Size' <SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyErr_Print'
<SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyString_FromStringAndSize' <SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyBaseObject_Type'
<SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyDict_Keys' <SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyArg_ParseTupleAndKeywords'
<SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyErr_Clear' <SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyString_Concat'
<SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to PyNumber_Xor' <SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference toPyNumber_Or'
<SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0: undefined reference to `PyNumber_Index'
[...]

The error does NOT appear when building on

Ubuntu 10.04 LTS / g++ (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3

but appears when building on

Ubuntu 12.04 LTS / g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

Command:

Note: to facilitate the reading, I changed '/home/crmullin/Projects/Slicer4-SuperBuild-Debug' into '<SUPERBUILD>' and also changed spaces into newlines.

/usr/bin/c++
-Wall
-Wextra
-Wpointer-arith
-Winvalid-pch
-Wcast-align
-Wwrite-strings
-D_FORTIFY_SOURCE=2
-fdiagnostics-show-option
-Wl,--no-undefined
-fstack-protector-all
-Wno-deprecated
-Woverloaded-virtual
-Wstrict-null-sentinel
-ftemplate-depth-50
-Wall
-Wno-deprecated
-msse2
-ftemplate-depth-50
-Wall
-Wno-deprecated
-g
-lpthread
CMakeFiles/qSlicerDataModuleWidgetsCxxTests.dir/qSlicerDataModuleWidgetsCxxTests.cxx.o
CMakeFiles/qSlicerDataModuleWidgetsCxxTests.dir/qMRMLNodeAttributeTableViewTest.cxx.o
CMakeFiles/qSlicerDataModuleWidgetsCxxTests.dir/qMRMLNodeAttributeTableWidgetTest.cxx.o

-o
../../../../../bin/qSlicerDataModuleWidgetsCxxTests
-rdynamic
-L<SUPERBUILD>/ITKv3-build/bin
-L<SUPERBUILD>/CTK-build/CMakeExternals/Install/lib
-L<SUPERBUILD>/teem-build/bin
-L<SUPERBUILD>/cmcurl-build/bin
-L<SUPERBUILD>/OpenIGTLink-build/bin
../../../../../lib/Slicer-4.1/qt-loadable-modules/libqSlicerDataModuleWidgets.so
../../../../../bin/libqSlicerBaseQTGUI.so
../../../../../bin/libqSlicerBaseQTCore.so
../../../../../bin/libSlicerBaseLogic.so
../../../../../bin/libMRMLCLI.so
<SUPERBUILD>/qMidasAPI-build/libqMidasAPI.a
<SUPERBUILD>/SlicerExecutionModel-build/ModuleDescriptionParser/bin/libModuleDescriptionParser.so
-lpthread
../../../../../bin/libqMRMLWidgets.so
/home/crmullin/QtSDK/Desktop/Qt/474/gcc/lib/libQtScript.so
/home/crmullin/QtSDK/Desktop/Qt/474/gcc/lib/libQtSvg.so
/home/crmullin/QtSDK/Desktop/Qt/474/gcc/lib/libQtUiTools.a
/home/crmullin/QtSDK/Desktop/Qt/474/gcc/lib/libQtTest.so
../../../../../bin/libMRMLDisplayableManager.so
<SUPERBUILD>/VTK-build/bin/libvtkCommonPythonD.so.5.10.0
<SUPERBUILD>/CTK-build/CTK-build/bin/libCTKImageProcessingITKCore.so.0.1.0
<SUPERBUILD>/CTK-build/CTK-build/bin/libCTKQtTesting.so.0.1.0
<SUPERBUILD>/CTK-build/CTK-build/bin/libCTKDICOMWidgets.so.0.1.0
<SUPERBUILD>/CTK-build/CTK-build/bin/libCTKDICOMCore.so.0.1.0
<SUPERBUILD>/CTK-build/CMakeExternals/Install/lib/libdcmimage.a
<SUPERBUILD>/CTK-build/CMakeExternals/Install/lib/libdcmimgle.a
<SUPERBUILD>/CTK-build/CMakeExternals/Install/lib/libdcmnet.a
<SUPERBUILD>/CTK-build/CMakeExternals/Install/lib/libdcmjpeg.a
<SUPERBUILD>/CTK-build/CMakeExternals/Install/lib/libdcmdata.a
<SUPERBUILD>/CTK-build/CMakeExternals/Install/lib/libijg8.a
<SUPERBUILD>/CTK-build/CMakeExternals/Install/lib/libijg12.a
<SUPERBUILD>/CTK-build/CMakeExternals/Install/lib/libijg16.a
<SUPERBUILD>/CTK-build/CMakeExternals/Install/lib/liboflog.a
<SUPERBUILD>/CTK-build/CMakeExternals/Install/lib/libofstd.a
<SUPERBUILD>/CTK-build/CTK-build/bin/libCTKVisualizationVTKWidgets.so.0.1.0
<SUPERBUILD>/VTK-build/bin/libvtkCharts.so.5.10.0
<SUPERBUILD>/VTK-build/bin/libQVTK.so.5.10.0
/home/crmullin/QtSDK/Desktop/Qt/474/gcc/lib/libQtWebKit.so
<SUPERBUILD>/VTK-build/bin/libvtkViews.so.5.10.0
<SUPERBUILD>/VTK-build/bin/libvtkInfovis.so.5.10.0
<SUPERBUILD>/VTK-build/bin/libvtkWidgets.so.5.10.0
<SUPERBUILD>/VTK-build/bin/libvtkVolumeRendering.so.5.10.0
<SUPERBUILD>/CTK-build/CTK-build/bin/libCTKVisualizationVTKCore.so.0.1.0
<SUPERBUILD>/VTK-build/bin/libvtkPythonCore.so.5.10.0
../../../../../bin/libMRMLLogic.so
<SUPERBUILD>/LibArchive-install/lib/libarchive.so
../../../../../bin/libRemoteIO.so
../../../../../bin/libMRMLCore.so
<SUPERBUILD>/VTK-build/bin/libvtkHybrid.so.5.10.0
<SUPERBUILD>/VTK-build/bin/libvtkParallel.so.5.10.0
<SUPERBUILD>/VTK-build/bin/libvtkRendering.so.5.10.0
-lGL
-lSM
-lICE
-lX11
-lXext
../../../../../bin/libvtkTeem.so
<SUPERBUILD>/VTK-build/bin/libvtkGraphics.so.5.10.0
-lteem
<SUPERBUILD>/VTK-build/bin/libvtkzlib.so
<SUPERBUILD>/VTK-build/bin/libvtkpng.so
<SUPERBUILD>/VTK-build/bin/libvtkzlib.so
<SUPERBUILD>/VTK-build/bin/libvtkpng.so
../../../../../bin/libvtkITK.so
-lITKAlgorithms
-lITKNumerics
-lITKStatistics
-litkNetlibSlatec
-lITKFEM
-lITKBasicFilters
-lITKIO
-lITKNrrdIO
-litkgdcm
-litkjpeg12
-litkjpeg16
-litkopenjpeg
-litkpng
-litktiff
-litkjpeg8
-lITKSpatialObject
-lITKMetaIO
-lITKDICOMParser
-lITKEXPAT
-lITKniftiio
-lITKznz
-litkzlib
-lITKTransformIOReview
-lITKQuadEdgeMesh
-lITKCommon
-litkvnl_inst
-litkvnl_algo
-litkv3p_netlib
-litkvnl
-litkvcl
-litkv3p_lsqr
-litksys
<SUPERBUILD>/VTK-build/bin/libvtkImaging.so.5.10.0
../../../../../bin/libFreeSurfer.so
<SUPERBUILD>/VTK-build/bin/libvtkIO.so.5.10.0
<SUPERBUILD>/VTK-build/bin/libvtkFiltering.so.5.10.0
<SUPERBUILD>/VTK-build/bin/libvtkCommon.so.5.10.0
-lm
<SUPERBUILD>/VTK-build/bin/libvtksys.so.5.10.0
-lpthread
-lm
<SUPERBUILD>/VTK-build/bin/libvtkzlib.so.5.10.0
-lslicerlibcurl
<SUPERBUILD>/CTK-build/CTK-build/bin/libCTKScriptingPythonWidgets.so.0.1.0
<SUPERBUILD>/CTK-build/CTK-build/bin/libCTKScriptingPythonCore.so.0.1.0
<SUPERBUILD>/python-build/lib/libpython2.6.so
<SUPERBUILD>/CTK-build/CMakeExternals/Install/lib/libPythonQt.so
-lutil
<SUPERBUILD>/CTK-build/CTK-build/bin/libCTKWidgets.so.0.1.0
<SUPERBUILD>/CTK-build/QtTesting-build/libQtTesting.so
<SUPERBUILD>/CTK-build/CTK-build/bin/libCTKCore.so.0.1.0
/home/crmullin/QtSDK/Desktop/Qt/474/gcc/lib/libQtXml.so
/home/crmullin/QtSDK/Desktop/Qt/474/gcc/lib/libQtOpenGL.so
/home/crmullin/QtSDK/Desktop/Qt/474/gcc/lib/libQtXmlPatterns.so
/home/crmullin/QtSDK/Desktop/Qt/474/gcc/lib/libQtGui.so
/home/crmullin/QtSDK/Desktop/Qt/474/gcc/lib/libQtSql.so
/home/crmullin/QtSDK/Desktop/Qt/474/gcc/lib/libQtNetwork.so
/home/crmullin/QtSDK/Desktop/Qt/474/gcc/lib/libQtCore.so
-ldl
-Wl,-rpath,<SUPERBUILD>/ITKv3-build/bin:<SUPERBUILD>/CTK-build/QtTesting-build:<SUPERBUILD>/CTK-build/CMakeExternals/Install/lib:<SUPERBUILD>/teem-build/bin:<SUPERBUILD>/cmcurl-build/bin:<SUPERBUILD>/OpenIGTLink-build/bin:<SUPERBUILD>/Slicer-build/lib/Slicer-4.1/qt-loadable-modules:<SUPERBUILD>/Slicer-build/bin:<SUPERBUILD>/SlicerExecutionModel-build/ModuleDescriptionParser/bin:/home/crmullin/QtSDK/Desktop/Qt/474/gcc/lib:<SUPERBUILD>/VTK-build/bin:<SUPERBUILD>/CTK-build/CTK-build/bin:<SUPERBUILD>/LibArchive-install/lib:<SUPERBUILD>/python-build/lib
-Wl,-rpath-link,<SUPERBUILD>/VTK-build/bin

Thanks for your help,

Bill answer:

You should find out where this symbol is supposed to be:
PyType_IsSubtype

Go to a system that works, and run nm on all the libraries that slicer links to. Pipe that to nm and find PyType_IsSubtype. Then make sure that library is being linked on the machine where it does not work.

I would guess that this symbol is supposed to be part of python itself. Perhaps the python is built with some option off?

Jc reply:

// ----------------------------
Folks,

To answer the question of Bill:
Yes, the symbol are all present in the python library build by Slicer. The build option associated with the python library are the same between the two systems.

Looking at the code used to build vtkPythonCore, I found the following:

Underlinking on purpose. The following library will not compile

with LDFLAGS=-Wl,--no-undefined by design:

On some UNIX platforms the python library is static and therefore

should not be linked into the shared library. Instead the symbols

are exported from the python executable so that they can be used by

shared libraries that are linked or loaded. On Windows and OSX we

want to link to the python libray to resolve its symbols

immediately.

IF(WIN32 OR APPLE)
TARGET_LINK_LIBRARIES (vtkPythonCore ${VTK_PYTHON_LIBRARIES})
TARGET_LINK_LIBRARIES (vtkPythonCore LINK_INTERFACE_LIBRARIES ${VTK_PYTHON_LIBRARIES})
ENDIF(WIN32 OR APPLE)

See http://vtk.org/gitweb?p=VTK.git;a=blob;f=Wrapping/Python/CMakeLists.txt;h=d59ef4c5b2d40e9c5a8e1bf74c9571a7549584bc;hb=9e66eb8fde3edee8382d2fd8700cfbc61ea019cb#l50

Then, looking at how the "vtkpython" executable is linked, I found that it is linked against python using the following:

TARGET_LINK_LIBRARIES(vtkpython ${VTKPYTHON_LINK_LIBS})
TARGET_LINK_LIBRARIES(vtkpython LINK_INTERFACE_LIBRARIES ${VTK_PYTHON_LIBRARIES})

where

VTK_PYTHON_LIBRARIES point to the python library

and

VTKPYTHON_LINK_LIBS is set to the complete list of VTK libraries. See http://vtk.org/gitweb?p=VTK.git;a=blob;f=Wrapping/Python/CMakeLists.txt;h=d59ef4c5b2d40e9c5a8e1bf74c9571a7549584bc;hb=9e66eb8fde3edee8382d2fd8700cfbc61ea019cb#l198

Two message statements added into the Wrapping/Python/CMakeLists.txt print the following:

VTKPYTHON_LINK_LIBS:/home/jchris/Projects/Slicer4-Superbuild-Debug/python-build/lib/libpython2.6.so;vtksys;vtkCommon;vtkFiltering;vtkIO;vtkGraphics;vtkImaging;/usr/lib/libutil.so;vtkRendering;vtkVolumeRendering;vtkHybrid;vtkWidgets;vtkParallel;vtkCharts;vtkGeovis;vtkInfovis;vtkViews

VTK_PYTHON_LIBRARIES:/home/jchris/Projects/Slicer4-Superbuild-Debug/python-build/lib/libpython2.6.so

What is interesting is that to build the main application "SlicerApp-real", I don't have to use LINK_INTERFACE_LIBRARIES f, it's probably related to the fact all the required dependencies end up being added to the link command.

I guess I will have to specify the missing dependency so that qSlicerDataModuleWidgetsCxxTests can be linked properly.

What do you all think ? Am I missing misunderstanding something ?

Blaming the file, David Gobbi added these lines ... will also ask him his feedback.

From David:

Hi J-C,

Any executable that uses python should include ${VTK_PYTHON_LIBRARIES}
in its target_link_libraries.

For python modules, linking to just vtkPythonCore will often be enough
because they can resolve their symbols directly against the python
executable. But executables that use python functions should always
link to ${VTK_PYTHON_LIBRARIES}. You can't trust that vtkPythonCore
will automatically bring in VTK_PYTHON_LIBRARIES.

Topic pushed on https://github.com/jcfr/Slicer/compare/2321-fix-python-link-error-gcc-46

I can confirm this bug on clean Ubuntu build (git treeish: a1dda866aee9a05e9b53ff841f942ad330153323). JC, can you push the fix to the main Slicer repo?

Thanks. Jc is out for the next few weeks, I'll look into the topic shortly.

The current branch fix doesn't solve the issue on Ubuntu Oneric with gcc 4.6.1.

Is there a way to reproduce the error with the Volumes module ? May be trying to move in that direction will give some hints ?

Newer gcc versions are stricter about both library order and explicit linking.

http://stackoverflow.com/questions/7826448/linking-libraries-with-gcc-order-of-arguments
http://stackoverflow.com/questions/8725572/gcc-4-5-vs-4-4-linking-with-dependencies
http://stackoverflow.com/questions/7773811/gcc-compile-has-undefined-references-despite-previously-functional-linking-ubunt

google "link order gcc 4.6 undefined reference site:stackoverflow.com" for dozens of similar problems.

I tried some manual variations of the library order in the g++ call to build this test, with no success yet. Hopefully this gives a clue where to look.

Also in link 3 above, it suggests a workaround is to install package "binutils-gold", which provides a new and purportedly faster version of ld from google. installing this did resolve the issue for me - and hopefully will speed up builds as well.

Thank you inorton for the tips in solving this issue.

JC, I will check it with binutils-gold. However, I don't think this is a solution. The gold linker is a faster replacement for the GNU linker(default linker). I mean, if the order of libraries and source files is the issue, it is better to fix that. I am working on Slicer-4.2 tutorial issues and will get to this one as soon as I am done with that.

I agree this is not the optimum fix but if by installing gold, it works. I think it's okay for now.

I would suggest to discuss the issue with CMake folks.

Can you please disable this test until a correct solution is found? This test does not justify a broken build on newer linux distros. gcc 4.6 has been main-line for over a year now for two of the important platforms (ubuntu 11.10+, fedora 15+) and users reasonably expect Slicer to compile out-of-the-box with default tools from build-essentials.

Okay, finally with some awesome help from Bill Hoffman we could figure out what was the root cause of this problem.

Turns out, the shared library libvtkPythonCore.so uses python symbols but is not linked to libpython.so https://github.com/Kitware/VTK/blob/v5.10.0/Wrapping/Python/CMakeLists.txt#L50 . Moreover, the test in question - qSlicerDataModuleWidgetsCxxTest does not reference any python symbols directly. This makes the linker "not link" the executable to libpython. However, since libvtkPythonCore depends on libpython without a direct link between the two, we have to suffer with this bug. :-(

In essence, if there is a shared library "A" that depends on a shared library "B" but is not linked directly to it and an executable "C" depends only on shared library "A", linker fails to link to library "B" and cannot resolve symbols in "A".

Now, you would expect the linker to resolve the dependency up the toolchain and link the two shared libraries together. This would have made it much easier. But, Ubuntu package maintainers decided to add a linker flag "--as-needed"(http://linux.die.net/man/1/ld) to the default gcc toolchain starting Ubuntu 12.04.
There is some discussion on this(http://stackoverflow.com/questions/12693624/references-to-fftw-not-resolved-when-linking-with-as-needed).

To fix this problem, we have two options,

1. Add some simple try_compile code in top-level CMakeLists.txt checking whether the linker links between inter-dependent shared libraries. If it does not, we can pass a "--no-as-needed" flag to the linker.

2. Force the "--no-as-needed" flag on the linker. This may not be an elegant solution for all cases and platforms.

As an aside, I will talk to VTK folks to check if there is a reason behind not linking libvtkPythonCore with libPython.

Any suggestions/ideas, please feel free to pass them on.

Why does this only happen for qSlicerDataModuleWidgetsCxxTest? We have many tests and other code that does not reference python symbols, why is this different?

Playing with linker flags to resolve this seems like a bad idea. This is at least a meta-bug, possibly twice removed.

This happens only for qSlicerDataModuleWidgetsCxxTest because that might be the oddball referencing symbols from libvtkPythonCore.so but not from libpython.so. That is why the linker is not bringing in the shared library libpython.so

To verify, this I added referenced a python symbol in the test and it all compiled fine.

I didn't quite understand what you mean by a meta-bug?
The real problem is a linker flag (--as-needed) and all I have to do is set the variable CMAKE_EXE_LINKER_FLAGS in the CMakeCache for Slicer to --no-as-needed. I verified this as well.

Pushed the topic
https://github.com/sankhesh/Slicer/tree/2321-gcc4.6-linker

with the said changes.

Fixed in r21158 (http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=21158)

On my mac build I get this error now when running cmake:

CMake Warning at CMake/SlicerLinkerAsNeededFlagCheck.cmake:53 (message):
Could not compile test code.Linker could fail trying to resolve symbols for
underlinked libraries.See issue 2321
(http://na-mic.org/Mantis/view.php?id=2321) for more details.
Call Stack (most recent call first):
CMakeLists.txt:86 (include)

see note from Steve

Its fixed in r21167 (http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=21167). The check should not be done on Mac as it follows a different linking algorithm. Secondly, there is no --as-needed flag for the linker on Mac. Kindly test it and close this issue.

additional comments by sankhesh clarified issue