[Paraview-developers] UNIX runtime paths and VTK_USE_RPATH

[Brad King]

Hello, all:

In the past if a user built ParaView or VTK with shared libraries and
did not set CMAKE_SKIP_RPATH to OFF then the installed binaries would
have rpaths pointing at the build tree.  This would cause
installations to break when the build trees were removed or updated.

It is generally not safe to install binaries that use a runtime path,
especially one that points to the build tree.  The reason rpath
support is provided by ParaView and VTK is so that shared library
builds can run in the build tree out of the box without setting any
environment variables like LD_LIBRARY_PATH.  This is very useful for
testing because dashboard scripts do not have to know how to set this
environment variable.  However, it is no good for installation.

To solve this problem for VTK we created the setting VTK_USE_RPATH.
If set to ON then rpaths will be built into the binaries, but
attempting to install produces an error message and nothing installs.
If set to OFF then rpaths will not be built into the binaries and
installation will work, but running tests requires setting of
LD_LIBRARY_PATH or similar variable in the environment.  For release
versions it defaults to OFF so that users can download and install VTK
out of the box.  For development versions (only available from CVS) it
defaults to ON so that dashboards will continue to work.

In ParaView we have another option that I'd like to discuss.  For the
ParaView 2.x binary releases on UNIX platforms I created the
KWSys/SharedForward utility.  When CMAKE_SKIP_RPATH is ON (forced now
by VTK_USE_RPATH being OFF), the paraview executables are built with a
"-real" extension on their name (like "pvserver-real").  Small
forwarding executables with the original names (like "pvserver") are
built and do not link to anything but system libraries.  These small
executables detect whether they are running from a build or install
tree, set LD_LIBRARY_PATH appropriately in the environment, and
replace themselves via "exec" with the corresponding real executable.

This design allows ParaView to run out of a build tree or any install
tree without any special environment settings.  The drawback is that
in order to run a debugger some extra effort is needed to debug the
real version of the executable.  Typically one might have to do this:

$ bin/paraview --print
LD_LIBRARY_PATH=/home/kingb/Programs/ParaView-gcc/bin
/home/kingb/Programs/ParaView-gcc/bin/paraview-real
$ export LD_LIBRARY_PATH=/home/kingb/Programs/ParaView-gcc/bin
$ gdb /home/kingb/Programs/ParaView-gcc/bin/paraview-real

For this reason I have chosen to use the same default for
VTK_USE_RPATH in ParaView as I do in VTK: releases default to OFF and
development versions default to ON.  This way users can download and
install out of the box and develoers can build and debug out of the
box.  However, developers that use shared libraries have to know to
set VTK_USE_RPATH to OFF in order to install.

I'd like comments on whether the default for VTK_USE_RPATH in ParaView
should just always be OFF.  Thanks to the KWSys/SharedForward feature
this choice will not require anyone to set any environment variables
unless they want to run ParaView in a debugger.  However, running in
the debugger may be a pain as described above.

Comments?
-Brad