[vtkusers] VTK Python Wrappers on Red Hat

[Darren Weber]

On Sat, May 23, 2009 at 2:17 AM, Martin Costabel <costabel at wanadoo.fr>wrote:

> Darren Weber wrote:
>
>>
>> Hi Brian,
>>
>> I had similar problems in porting vtk 5.4.0 in macports.  My solutions
>> might work for you on linux:
>> https://trac.macports.org/browser/trunk/dports/graphics/vtk-devel/Portfile
>>
>> See variant py25 and py26, where the build bin path has to be replaced
>> with the install lib path for all the python shared libs (.dylib on OSX, .so
>> on linux).  Do you also have 'install_name_tool' on linux?
>>
>
> There is a second alternative for working around this problem, which I
> consider a bug in cmake:
>
> You chose the option, together with -DVTK_USE_RPATH:BOOL=ON,
>
>  -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF \
>
> In this case, cmake uses the build path as rpath during build time, and it
> replaces it with the install path at installation time. It does this for all
> binary executables and dynamic libs, but it forgets the python modules. This
> is what I call a bug in cmake, and you work around it by doing the rpath
> replacing for the python modules "by hand" after building is finished.
>
> The alternative is to use
>
>  -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \
>
> In this case, cmake puts the install path as rpath into all binaries and
> dynamic libs, including the python modules, at build time. This has the
> advantage that the rpath does not need to be modified at install time, but
> it has the drawback that you get a build time crash, because the rpath is
> not correct during build time, and the building of some binaries crashes
> because they don't find the dynamic libs they should link to. My workaround
> is to set the environment variable
>
>  export DYLD_LIBRARY_PATH=`pwd`/bin
>
> at build time, so that the dynamic libs are found by the linker.
>
> This second alternative is what I finally settled on for the Fink package
> of vtk54. Hopefully, in some future version of cmake, such a workaround
> won't be necessary, and we can use CMAKE_BUILD_WITH_INSTALL_RPATH=OFF
> directly.
>
> --
> Martin
>
>

I agree with everything that Martin said above, so clearly.

The same problems occur with InsightToolkit (ITK) and WrapITK.  In the
macport Portfiles that I've worked on recently, you can see examples of all
the post-install hacks required to reset the library paths.  The Portfiles
are pseudo tcl code, so if you set all the variables up, you could almost
copy and paste the post-destroot statements into tclsh8.4 and it might
work.  I don't want to recommend a straight copy and paste, because macports
is a peculiar beast when it comes to the installation process.

The alternative is to set the DYLD... environment variables, which seems to
work too.  I avoided that option, only because I don't know how to
interrogate these environment variables in macports during the build and
install process.  Without being confident that the linker could find an
additional install of the libraries (somewhere from a prior install or
whatever), I just opted to try and keep everything in cmake and some post
install hacks to reset lib paths.  It does get messy.  As it is, I believe
the macport Portfiles will continue to work even if cmake is fixed to
resolve this problem.

Anyhow, the main point is that wrapping in vtk and itk does not "obey" the
install rpath settings that are applied to the c++ binaries.  What a relief
it would be to see that change!  I have no idea how to do it, nor the time,
to submit a bug report on that.

Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20090525/27f8ffd6/attachment.htm>