[vtk-developers] Re: VTK Python Installation [was: VTK 5.0 branch in mid-August]
Brad King
brad.king at kitware.com
Wed Aug 3 15:27:07 EDT 2005
David Gobbi wrote:
> This sounds good. If the default behaviour of VTK's cmake; make; make
> install was to put versioned and rpath-free libraries into
> /usr/local/lib, that would be wonderful.
>
> I have spent a lot of time trying to help users who do "make install"
> and then get into trouble because the rpaths of the installed libraries
> point back to the source tree that they are monkeying with. In fact
> I've been bitten by this several times, myself. It seems that
> LD_LIBRARY_PATH is a better approach than rpath for running things from
> the source tree, and it would be easy to set LD_LIBRARY_PATH (or its
> equivalent depending on the flavor of UNIX) from a front-end script.
That would mean setting CMAKE_SKIP_RPATH in the VTK CMake code.
Unfortunately then we will get lots of questions from users trying to
run things from the build tree, and we will have to explain how to set
LD_LIBRARY_PATH. I keep so man VTK build trees around that it would be
impossible to remember which shell has which current LD_LIBRARY_PATH
setting. This is why we've been using rpath in the build tree.
Recently for ParaView I created the KWSys "SharedForward" feature. The
real executable target "paraview" is renamed to "paraview-real" and a
small C-only stand-alone executable called "paraview" is created using
SharedForward.h. This small executable knows how to set LD_LIBRARY_PATH
properly and then calls "exec" to load "paraview-real". In this way
ParaView can use shared libraries but run from the build tree or install
tree in any location without needing rpath. We could consider using
this feature for VTK too.
-Brad
More information about the vtk-developers
mailing list