[vtk-developers] Changes to vtkPlane broke build

[Marcus D. Hanwell]

On Friday 08 January 2010 10:32:59 Mathieu Malaterre wrote:
> 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)
> ...
> 
I am not sure I fully appreciate the logic here, but it does explain why this 
exploded on Linux, yet worked on Windows. It would be nice to be able to 
enable the linker flags above, but I don't want to cause any problems with our 
Python wrapping.

Could something like 'OR CMAKE_SYSTEM_NAME MATCHES Linux' be added to this if, 
or removing these linker flags just for the Python bindings possibly? I had 
put this on a back burner due to the issues with Python symbols, and I could 
ensure it is only enabled when building Debug, or possibly just a linker flag 
for the kits, not their bindings.

I am open to suggestions on what would be the best way to proceed. It would be 
good to catch more issues like this as soon as possible, and I have used these 
flags to great effect on other CMake built projects in the past.

Marcus
-- 
Marcus D. Hanwell, Ph.D.
R&D Engineer, Kitware Inc.
(518) 881-4937