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

[Mike Jackson]

On Sep 3, 2008, at 1:01 PM, Darren Weber wrote:

> 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 ;-)

I think OS X looks in /usr/lib as one of its default paths. /usr/local/ 
lib is NOT searched by default. Frameworks are a whole new beast. Not  
everything on OS X has to be a framework. Apple would like you to use  
them but lots of people get along with a standard unix style layout of  
bin, include, lib, share. You can build a framework if you want or you  
can use the standard unix layout. If you choose to just use a unix  
layout it is my suggestion to install it to /usr/local/MyProject/ or  
something like that although a common user would never know about this  
location. You can also use /Users/Shared/MyProject for that matter  
which is easier to find using the "Finder"

> 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:
>
> <snip>....
>
> 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
>>
>>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake

  _________________________________________________
| Mike Jackson - Principal Software Engineer      |
| BlueQuartz Software                             |
| mike.jackson at bluequartz.net                     |
| www.bluequartz.net                              |
---------------------------------------------------