[vtk-developers] Changes to vtkPlane broke build

[Mathieu Malaterre]

On Fri, Jan 8, 2010 at 4:09 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> On Friday 08 January 2010 08:14:24 Moreland, Kenneth wrote:
>> Not being as grumpy as John this morning, I can see how such a mistake
>>  could easily be made.  I am more confused as to why it did not give errors
>>  in MSVC.  I thought that  when a library or dll was created that the
>>  linker required that all symbols were accounted for (unlike Unix-type
>>  linkers).  At least that was how it worked in MSVC 6 and I think .net when
>>  I was still using it.  Maybe that changed.
>
> I have been looking at adding some extra compiler and linker warnings to GCC
> that may help in similar situations. I have not had time to fully test the
> changes but one affects the linker,
>
> set(CMAKE_SHARED_LINKER_FLAGS
>      "-Wl,--fatal-warnings -Wl,--no-undefined -lc
> ${CMAKE_SHARED_LINKER_FLAGS}")
>

If you are doing this, do not forget to de-activate python wrapping.

$ cat KitCommonPythonWrapBlock.cmake
...
# 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 (vtk${KIT}PythonD ${VTK_PYTHON_LIBRARIES})
ENDIF(WIN32 OR APPLE)
...

-- 
Mathieu