[vtkusers] VTK Python Wrappers on Red Hat

[Martin Costabel]

Darren Weber wrote:
> 
> Hi Brian,
> 
> I had similar problems in porting vtk 5.4.0 in macports.  My solutions 
> might work for you on linux:
> https://trac.macports.org/browser/trunk/dports/graphics/vtk-devel/Portfile
> 
> See variant py25 and py26, where the build bin path has to be replaced 
> with the install lib path for all the python shared libs (.dylib on OSX, 
> .so on linux).  Do you also have 'install_name_tool' on linux?

There is a second alternative for working around this problem, which I 
consider a bug in cmake:

You chose the option, together with -DVTK_USE_RPATH:BOOL=ON,

   -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF \

In this case, cmake uses the build path as rpath during build time, and 
it replaces it with the install path at installation time. It does this 
for all binary executables and dynamic libs, but it forgets the python 
modules. This is what I call a bug in cmake, and you work around it by 
doing the rpath replacing for the python modules "by hand" after 
building is finished.

The alternative is to use

   -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \

In this case, cmake puts the install path as rpath into all binaries and 
dynamic libs, including the python modules, at build time. This has the 
advantage that the rpath does not need to be modified at install time, 
but it has the drawback that you get a build time crash, because the 
rpath is not correct during build time, and the building of some 
binaries crashes because they don't find the dynamic libs they should 
link to. My workaround is to set the environment variable

  export DYLD_LIBRARY_PATH=`pwd`/bin

at build time, so that the dynamic libs are found by the linker.

This second alternative is what I finally settled on for the Fink 
package of vtk54. Hopefully, in some future version of cmake, such a 
workaround won't be necessary, and we can use 
CMAKE_BUILD_WITH_INSTALL_RPATH=OFF directly.

-- 
Martin