<br><br><div class="gmail_quote">On Sat, May 23, 2009 at 2:17 AM, Martin Costabel <span dir="ltr"><<a href="mailto:costabel@wanadoo.fr">costabel@wanadoo.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Darren Weber wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Hi Brian,<br>
<br>
I had similar problems in porting vtk 5.4.0 in macports. Â My solutions might work for you on linux:<br>
<a href="https://trac.macports.org/browser/trunk/dports/graphics/vtk-devel/Portfile" target="_blank">https://trac.macports.org/browser/trunk/dports/graphics/vtk-devel/Portfile</a><br>
<br>
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?<br>
</blockquote>
<br></div>
There is a second alternative for working around this problem, which I consider a bug in cmake:<br>
<br>
You chose the option, together with -DVTK_USE_RPATH:BOOL=ON,<br>
<br>
 -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF \<br>
<br>
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.<br>
<br>
The alternative is to use<br>
<br>
 -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \<br>
<br>
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<br>
<br>
 export DYLD_LIBRARY_PATH=`pwd`/bin<br>
<br>
at build time, so that the dynamic libs are found by the linker.<br>
<br>
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.<br>
<br>
-- <br><font color="#888888">
Martin<br>
<br>
</font></blockquote><div><br><br>I agree with everything that Martin said above, so clearly.<br><br>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.<br>
<br>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.<br>
<br></div></div>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.<br>
<br>Darren<br><br>