View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007935ParaView(No Category)public2008-11-04 09:062016-08-12 09:57
ReporterKen Moreland 
Assigned ToDavid Partyka 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007935: Add ability to fix library links in plugin
DescriptionThe 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).
TagsNo tags attached.
Project
Topic Name
Type
Attached Filesgz file icon TransformImagePlugin.tar.gz [^] (2,719 bytes) 2010-12-01 12:42

 Relationships
related to 0007348closedBurlen Add an option to Paraview's CMake to allow development installs 

  Notes
(0014025)
Ken Moreland (manager)
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 (developer)
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 (manager)
2010-11-30 22:13

 I believe Dave is correct. If this is still an issue, please reopen this bug.
(0023643)
Ken Moreland (manager)
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 (developer)
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 (manager)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2008-11-04 09:06 Ken Moreland New Issue
2008-11-04 09:06 Ken Moreland Relationship added related to 0007348
2008-11-04 09:09 Ken Moreland Note Added: 0014025
2009-02-17 14:40 Utkarsh Ayachit Category 3.6 => 3.8
2009-05-13 13:41 Utkarsh Ayachit Target Version => 3.8
2010-11-26 13:41 David Partyka Assigned To => David Partyka
2010-11-26 13:41 David Partyka Status backlog => tabled
2010-11-30 22:09 David Partyka Note Added: 0023613
2010-11-30 22:10 David Partyka Note Deleted: 0023613
2010-11-30 22:10 David Partyka Note Added: 0023614
2010-11-30 22:10 David Partyka Status tabled => @80@
2010-11-30 22:10 David Partyka Fixed in Version => 3.8
2010-11-30 22:10 David Partyka Resolution open => fixed
2010-11-30 22:13 Alan Scott Note Added: 0023617
2010-11-30 22:13 Alan Scott Status @80@ => closed
2010-12-01 12:42 Ken Moreland File Added: TransformImagePlugin.tar.gz
2010-12-01 12:49 Ken Moreland Note Added: 0023643
2010-12-01 12:49 Ken Moreland Status closed => @20@
2010-12-01 12:49 Ken Moreland Resolution fixed => reopened
2010-12-01 12:50 Ken Moreland Target Version 3.8 => 3.10
2010-12-01 14:25 David Partyka Note Added: 0023646
2010-12-01 15:15 Ken Moreland Note Added: 0023648
2010-12-01 15:15 Ken Moreland Status @20@ => tabled
2011-06-16 13:10 Zack Galbreath Category => (No Category)
2016-08-12 09:57 Kitware Robot Note Added: 0037601
2016-08-12 09:57 Kitware Robot Status expired => closed
2016-08-12 09:57 Kitware Robot Fixed in Version 3.8 =>
2016-08-12 09:57 Kitware Robot Resolution reopened => moved

Copyright © 2000 - 2018 MantisBT Team