3.1.2: ResetCameraClippingRange Missing

[Randall Hopper]

Ken Martin:
 |Randall Hopper:
 |>     Many of the VTK examples in 3.1.2 fail because the argument-less
 |>version of vtkRenderer::ResetCameraClippingRange() isn't available.
 |
 |Hello Randall,
 |
 |I am not seeing this behavior here. Could you have old libraries or 
 |something like that ?

I didn't think so.  To make sure, I'd set LD_LIBRARY_PATH before and got
the same errors.  However, I dug deeper into this problem this morning, and
it turns out you're right.  Sorry for the confusion.

Despite my having compiled in the appropriate RPATHs into VTK as before,
the "vtk" executable was dynamically linking with old VTK libs in
/usr/local/lib.

The reason is a bit bizarre, and I'll briefly outline it for the archives
and other IRIX users.  On IRIX (6.5.7f at least) RPATH specs for dependent
shared libraries are prepended to the parent's RPATH spec when linking the
executable.  Not good.

IN PARTICULAR:

   Built VTK locally (--prefix=$HOME/software/vtk) with an RPATH for
   where the VTK libs will live (-rpath $HOME/software/vtk/lib) so vtk could
   find them.  "vtk" also links with libtcl.so, and Tcl's default generated
   UNIX makefile contains a rogue RPATH in it for /usr/local/lib which is
   compiled into libtcl.

   Due to the broken IRIX RPATH behavior and the /usr/local/lib RPATH in
   libtcl, the "vtk" executable's RPATH looks like this:

           /usr/local/lib:$HOME/software/vtk/lib

   So if you have old versions of the VTK libs in /usr/local/lib, that's
   where vtk will pull them from.

   Also note that unlike Solaris, LD_LIBRARY_PATH on IRIX does not override
   the compiled-in RPATH (see rld(5)), so it does you no good in this case.

WORKAROUND:

   The workaround for this is: you have to extricate yourself from all
   libraries living in or with RPATHs to common directories containing old
   versions of libraries you need to link with.  Or, modify makefiles and
   link with all libraries using full paths (from rld(5), it appears the
   latter will work but I haven't tried it; this may be problematic if you
   don't have control of the source code).

   I chose the former route, compiling Tcl/Tk locally and linking VTK with
   that tree.

Randall
--------------------------------------------------------------------
This is the private VTK discussion list. Please keep messages on-topic.
Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
<majordomo at public.kitware.com>. For help, send message body containing
"info vtkusers" to the same address.
--------------------------------------------------------------------