MantisBT - ParaView
View Issue Details
0007935ParaView(No Category)public2008-11-04 09:062016-08-12 09:57
Ken Moreland 
David Partyka 
normalminorhave not tried
closedmoved 
 
 
0007935: Add ability to fix library links in plugin
The current ParaView build has an install make target that, in addition to copying files to the install directory, "fixes" the rpaths for all shared libraries and executables to point to those installed in the ParaView bundle.

In order for a plugin to be used with an installed ParaView, its rpaths also need to be mangled in the same way (it magically works when loaded by a running ParaView even if the plugin is not in the bundle directory).
No tags attached.
related to 0007348closed Burlen Add an option to Paraview's CMake to allow development installs 
gz TransformImagePlugin.tar.gz (2,719) 2010-12-01 12:42
https://www.vtk.org/Bug/file/8542/TransformImagePlugin.tar.gz
Issue History
2008-11-04 09:06Ken MorelandNew Issue
2008-11-04 09:06Ken MorelandRelationship addedrelated to 0007348
2008-11-04 09:09Ken MorelandNote Added: 0014025
2009-02-17 14:40Utkarsh AyachitCategory3.6 => 3.8
2009-05-13 13:41Utkarsh AyachitTarget Version => 3.8
2010-11-26 13:41David PartykaAssigned To => David Partyka
2010-11-26 13:41David PartykaStatusbacklog => tabled
2010-11-30 22:09David PartykaNote Added: 0023613
2010-11-30 22:10David PartykaNote Deleted: 0023613
2010-11-30 22:10David PartykaNote Added: 0023614
2010-11-30 22:10David PartykaStatustabled => @80@
2010-11-30 22:10David PartykaFixed in Version => 3.8
2010-11-30 22:10David PartykaResolutionopen => fixed
2010-11-30 22:13Alan ScottNote Added: 0023617
2010-11-30 22:13Alan ScottStatus@80@ => closed
2010-12-01 12:42Ken MorelandFile Added: TransformImagePlugin.tar.gz
2010-12-01 12:49Ken MorelandNote Added: 0023643
2010-12-01 12:49Ken MorelandStatusclosed => @20@
2010-12-01 12:49Ken MorelandResolutionfixed => reopened
2010-12-01 12:50Ken MorelandTarget Version3.8 => 3.10
2010-12-01 14:25David PartykaNote Added: 0023646
2010-12-01 15:15Ken MorelandNote Added: 0023648
2010-12-01 15:15Ken MorelandStatus@20@ => tabled
2011-06-16 13:10Zack GalbreathCategory => (No Category)
2016-08-12 09:57Kitware RobotNote Added: 0037601
2016-08-12 09:57Kitware RobotStatusexpired => closed
2016-08-12 09:57Kitware RobotFixed in Version3.8 =>
2016-08-12 09:57Kitware RobotResolutionreopened => moved

Notes
(0014025)
Ken Moreland   
2008-11-04 09:09   
Right now I can get around the problem by copying the plugin .dylib file to the bin directory in the ParaView build and running make install of ParaView. The plugin gets picked up with the rest of the libraries and its rpaths are fixed (I just have to go fish it out of the bundle). However, this is a cumbersome process and not one that I want to describe to anyone. Furthermore, it will not be an option when compiling against a ParaView install (once bug 0007348 is complete).
(0023614)
David Partyka   
2010-11-30 22:10   
This is already fixed. On Linux a make install removes all rpaths as we use a Launcher (bin/paraview -> lib/paraview-x.y/paraview-real). In mac bundles the rpath is fixed up by BundleUtilities.
(0023617)
Alan Scott   
2010-11-30 22:13   
I believe Dave is correct. If this is still an issue, please reopen this bug.
(0023643)
Ken Moreland   
2010-12-01 12:49   
I disagree. I do not consider this bug fixed at all. Dave's notes about the rpath being fixed certainly work for plugins located in the ParaView/Plugins source directory. That has been working since before I raised that bug (and in fact the workaround I post in the first note take advantage of this). However, this bug is referencing plugins that are built independent from ParaView like the one I just attached to this report.

When you build this plugin, how do you run install on it? How do you run BundleUtilities on it? I know of no way to do this. If it exists, it should be documented on the appropriate Wiki page (http://www.paraview.org/Wiki/Plugin_HowTo [^]) as part of a new heading with a title like "Distributing Built Plugins".
(0023646)
David Partyka   
2010-12-01 14:25   
Ahh, I see where you are coming from. I presumed you meant plugins built by ParaView.

On the Mac I can 'fixup' where the plugin locates it's ParaView/VTK dependencies relatively by replacing absolute paths with @executable/../../Library.

On Linux I am less sure. I would be tempted to strip all rpath and require the user to set LD_LIBRARY_PATH appropriately, but that would be a pain for users. I think newer Linux support relative rpath via embedding $Origin/../lib/paraview-3.10/ for each dependency but I will have to research this further.

Does this sound like a reasonable approach?
(0023648)
Ken Moreland   
2010-12-01 15:15   
That sounds good.

I admit to be pretty naive about how rpath works everywhere, but it was my understanding that the whole paraview/paraview-real approach was that the paraview stub application would set LD_LIBRARY_PATH to the appropriate lib directory and then call paraview-real, which has all of the rpaths stripped from it. If this is the case, wouldn't it be sufficient to just strip the rpaths from the plugin library? Since it is loaded by the paraview application that already has its LD_LIBRARY_PATH set, it should just find the right libraries, right?
(0037601)
Kitware Robot   
2016-08-12 09:57   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current ParaView Issues page linked in the banner at the top of this page.