[vtk-developers] [CMake] problems with VTK python module installation on OSX (after a custom build)

[Darren Weber]

Thanks heaps for some very useful insight into resolving my OSX nightmares.

It always helps to RTFM!  I was starting to think there is a problem
within the .so file and how it specifies the location of the dylib
required (path and version).  As yet, I have no idea how to "debug"
that.  I was stratching around for ldd or something and actually
started to read a couple of man pages on dlopen, but I didn't get far
enough with that and started to hack symlinks (no so elegant).  So, I
guess most of the dlopen paths point to framework locations (NeXT
stuff), rather than a full search of /usr/local/lib/, but I do have to
RTFM on that, among many other OSX things ;-)

Another option may be to hard code the paths in the .so build
(somehow), so that's another avenue to learn about (the build learning
curve is moderated by ccmake, but not entirely when you need to tweak
a few things).  I could not find instances of these variables in the
main ccmake interface:

-DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \
-DVTK_USE_RPATH=ON

Where are they set?  Are they set somewhere specific within the build tree?

In my build with this dylib problem, these are a few ccmake settings
(at the root level?) that may be relevant:

CMAKE_EXE_LINKER_FLAGS*   [empty]
CMAKE_SHARED_LINKER_FLAGS*   [empty]

CMAKE_USE_RELATIVE_PATHS   OFF

PYTHON_DEBUG_LIBRARY   /Library/Frameworks/python.framework
PYTHON_ENABLE_MODULE_*  ON
PYTHON_EXECUTABLE
/Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5
PYTHON_EXTRA_LIBS   [empty]
PYTHON_INCLUDE_PATH   /Library/Frameworks/Python.framework/Headers
PYTHON_LIBRARY   /Library/Frameworks/Python.framework
PYTHON_MODULE_*   ON
PYTHON_UTIL_LIBRARY   /usr/lib/libutil.dylib

VTK_NO_PYTHON_THREADS   OFF
VTK_PYTHON_SETUP_ARGS   --prefix="${CMAKE_INSTALL_PREFIX}"

VTK_USE_RPATH   OFF


Again, thanks!

Darren




On Wed, Sep 3, 2008 at 1:02 AM, Martin Costabel <costabel at wanadoo.fr> wrote:
>
> Darren Weber wrote:
> []
>>
>> ImportError: dlopen(/usr/local/lib/python2.5/site-packages/vtk/libvtkCommonPython.so, 10): Library not loaded: libvtkCommonPythonD.5.2.dylib
>>  Referenced from: /usr/local/lib/python2.5/site-packages/vtk/libvtkCommonPython.so
>>  Reason: image not found
>
> This is not a problem you can solve with PYTHONPATH. It is not python that is trying to find the dylib, but dlopen(). And dlopen does not look at PYTHONPATH.
>
> There are several different ways how you can solve this problem (as always on Mac OSX, given its hybrid Unix/NextStep nature):
>
> The simplest and cleanest way (this is how it is done by the Fink VTK package, for example, perhaps also by macports vtk5) is to build vtk in such a way that its dylibs have decent install_names that correspond to the place where they are installed. In this way, dlopen() finds the dylib without any help, because the full path name (or a correct relative path name) of the dylib is hardcoded inside the libvtkCommonPython.so python module. For example, I get from the command
>
> otool -L /sw/lib/python2.5/site-packages/vtk/libvtkCommonPython.so |head -n3
>
> the output:
>
> /sw/lib/python2.5/site-packages/vtk/libvtkCommonPython.so:
>        /sw/lib/vtk/libvtkCommonPythonD.5.0.dylib (compatibility version 5.0.0, current version 5.0.4)
>        /sw/lib/vtk/libvtkCommon.5.0.dylib (compatibility version 5.0.0, current version 5.0.4)
>
> You see the whole path of libvtkCommonPythonD.5.0.dylib there. I am sure in your case, you will see only "libvtkCommonPythonD.5.0.dylib", without its path. This is the default when building VTK. If you want to get the correct install_name, you have to build VTK (this is for 5.0, I haven't tried 5.2 yet) with the cmake parameters
>
>
>  -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \
>  -DVTK_USE_RPATH=ON
>
> Another way to help dlopen, if your VTK is built without install_names for its dylibs, is to use one of the environment variables LD_LIBRARY_PATH, DYLD_FALLBACK_LIBRARY_PATH or DYLD_LIBRARY_PATH (do *not* use the latter, it risks wreaking havoc on your system). See "man dlopen".
>
> --
> Martin
>
>