[vtkusers] VTK on Tcl 8.6 and with re-locatable TCL files, and more

[Adam Williamson]

Hi, folks.

I recently started (experimentally) moving Mandriva's development branch
(Cooker) to Tcl/Tk 8.6. Someone on the mailing list was worried about
whether VTK would work with it, and so I spent yesterday working on our
VTK package. I don't know a lot about VTK, but what I got seems to build
and work correctly; package require vtk works, vtk runs, and I can run
several of the testing things (I will try more later).

Please note that I am entirely looking at things from a Linux
perspective here. Much of this is probably not portable as-is to Windows
or other *nixes. This, I do not care about. :) It should be reasonably
easy to make properly portable.

Actually making it work with Tcl 8.6 is not that hard. I had to add the
necessary headers from Tcl/Tk 8.6 to Utilities/TclTk/internals . Then
the only remaining issue is a few uses of the deprecated
intern->result , which I filed as
http://www.vtk.org/Bug/view.php?id=7822 .

I did, however, have to make some more significant changes for another
issue: TCL location. With the change, I am adopting Fedora's policy -
which I find a very good one - that TCL packages should live
in /usr/share/tcl8.6 (arch-independent) or /usr/lib(64)/tcl8.6
(arch-dependent). Tcl is configured *only* to look in these directories
for packages, so it won't find any anywhere else - including VTK's
default location, which is /usr/lib/vtk-version/ , the location where
VTK libraries are installed. VTK's pkgInfo.tcl is built to assume that
it - which is installed as part of VTK_INSTALL_TCL_DIR - is in the same
place as the VTK libraries - which are installed as part of
VTK_INSTALL_LIB_DIR . In effect, VTK_INSTALL_TCL_DIR and
VTK_INSTALL_LIB_DIR must be identical or it won't work.

So I had to add the attached vtk-5.2.0-tcl_relocate.patch to fix this.
It simply changes pkgInfo.tcl.in to look for the TCL libraries in the
place where they were set to be installed - VTK_INSTALL_LIB_DIR . Note
that I had to use a bit of a hack to fix a problem I couldn't figure
out: when substituted into pkgInfo.tcl.in , VTK_INSTALL_LIB_DIR seems to
lose the prefix, so you get /lib/vtk-5.2 , not /usr/lib/vtk-5.2 . I
couldn't figure out how to get it back. This is probably not too hard
for someone else to fix. I just hard-coded /usr for now, which is
obviously ugly.

That patch also does something else useful: it makes it look for

libvtkFOO.so.5.2

rather than

libvtkFOO.so

on Mandriva (and probably other distributions), the unversioned .so
files usually go in -devel packages. If you have them in the main
library package, a) you can't have two majors installed at once (which
is the general point of bothering with SONAMES in the first place) and
b) you get a ton of auto-generated development dependencies. Urgh. So
this just appends . at VTK_MAJOR_VERSION@. at VTK_MINOR_VERSION@ to the
filename to use when searching for libraries. Again, this may well not
be entirely portable, but it could be conditionalized or something. I'm
not sure if anything else tries to open the libraries directly like
this, but at least in my testing I didn't have them installed (as
they're in the -devel packages, which I intentionally didn't install)
and everything seemed to work.

CMakeLists.txt also assumes /(prefix)/lib for libraries:

   SET(VTK_INSTALL_LIB_DIR 
    ${VTK_INSTALL_ROOT}/lib/vtk-${VTK_MAJOR_VERSION}.${VTK_MINOR_VERSION}

This isn't correct on several Linux distros, which use /usr/lib64 for
the x86-64 architecture. This can be resolved by using
${VTK_INSTALL_ROOT}/lib${LIB_SUFFIX} - LIB_SUFFIX being a CMake
convention (it's passed by our standard CMake invocation). Actually I
change this to just:

   SET(VTK_INSTALL_LIB_DIR 
+    ${VTK_INSTALL_ROOT}/lib${LIB_SUFFIX}

because having the shared libraries in a subdirectory of /usr/lib
doesn't work by default - it's not in ldconfig's path, so ldconfig
doesn't find them, so vtk doesn't run. How is this expected to work,
normally?

That's it for my work (well, there's a few dodges in %install , but
nothing major), but there's a patch and a workaround in our package from
other maintainers, which may be of interest.

vtk-gcc4.3.patch adds a couple of header fixes to make it build with GCC
4.3, by the looks of things.

%install contains this little stanza:

find -type f | xargs sed -i -e 's#../../../../VTKData#%{_datadir}/vtk-data#g'

which suggests that some stuff in the source tree does not respect the
-DVTK_DATA_ROOT setting, as it assumes a relative location for the VTK
data. grep shows these offenders:

[adamw at lenovo VTK]$ grep -R "\.\./\.\./\.\./\.\./VTKData" *
Common/Testing/Cxx/vtkTestUtilities.h:    "../../../../VTKData");
Common/Testing/Cxx/vtkTestUtilities.h:    "../../../../VTKData",
Rendering/vtkTesting.cxx:    "../../../../VTKData");
Wrapping/Python/vtk/util/misc.py:            dataRoot = '../../../../VTKData'
Wrapping/Python/vtk/test/Testing.py:          set the value defaults to '../../../../VTKData'.
Wrapping/Python/vtk/test/Testing.py:        VTK_DATA_ROOT = os.path.normpath("../../../../VTKData")
Wrapping/Tcl/vtkbase/vtkbase.tcl:            [file nativename [file join [file dirname [info script]] "../../../../VTKData"]]]
[adamw at lenovo VTK]$

possibly this stuff is only meant to be run in-tree, I'm not sure.

VTK also doesn't build with GCC's -Wl,--as-needed -Wl,--no-undefined
parameters , which protect against underlinking. There's several issues
there which I'm currently seeing if I can fix.
-- 
adamw
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtk-5.2.0-tcl_relocate.patch
Type: text/x-patch
Size: 1227 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20081017/dc14042d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtk-gcc4.3.patch
Type: text/x-patch
Size: 1404 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20081017/dc14042d/attachment-0001.bin>