MantisBT - ParaView
View Issue Details
0008673ParaView(No Category)public2009-03-04 16:432009-05-13 13:45
Burlen 
Burlen 
normalminorhave not tried
closedfixed 
 
3.6 
0008673: No way for plugins to load with dependencies that are not in default libray search paths
The following emails describe the problem.


Hi All,

I have a Paraview plugin depending on some shared libraries that
ParaView does not depend on. What's the best way to make Paraview know
about this dependency so that it can find the required libraries when
loading the plugin. Apparently, have all the required libraries in the
same directory as the plugin does not seem to work on Windows. I am
trying to accomplish this on both Windows and Mac. I assume this is a
common scenario, but I did not find an answer in the mailing list.

Thanks

Yumin



I am having a similar issue on Windows with the VisIt database bridge plugin. My issues would be solved if the loader would search the plugin's directory. It would be even better if a list of paths relative to the plugin's directory could be provided, maybe via CMake or xml.

Burlen


Yumin Yuan wrote:
> Thanks, Ken.
>
> I guess the question then is who should be be doing all that. I
> assume/wish Paraview's load-plugin module will handle that, or at
> least know to look for libraries in that plugin's directory, which is
> most likely where people will put all the dependency libraries when
> they hand off their plugins to someone else.
>
> Yumin
>
> On Wed, Mar 4, 2009 at 3:17 PM, Moreland, Kenneth <kmorel@sandia.gov> wrote:
>
>> I believe the dependent shared libraries should be found exactly the same
>> way as any other shared library. On Windows, it searches your PATH plus the
>> directory the application is run in (not the one the plugin is located in).
>> On Mac it searches DYLD_LIBRARY_PATH. In addition on Mac you can compile
>> with rpath flags to hardcode the full path to dependent shared libraries.
>>
>> On windows you can check the resolution of shared libraries using the
>> depends tool (although you might get misleading results if it finds
>> libraries in the current directory, I think). On Mac you can use otool with
>> the –L flag.
>>
>> -Ken
>>
>>
>> On 3/4/09 11:34 AM, "Yumin Yuan" <yumin.yuan@kitware.com> wrote:
>>
>> Hi All,
>>
>> I have a Paraview plugin depending on some shared libraries that
>> ParaView does not depend on. What's the best way to make Paraview know
>> about this dependency so that it can find the required libraries when
>> loading the plugin. Apparently, have all the required libraries in the
>> same directory as the plugin does not seem to work on Windows. I am
>> trying to accomplish this on both Windows and Mac. I assume this is a
>> common scenario, but I did not find an answer in the mailing list.
>>
>> Thanks
>>
>> Yumin
>> _______________________________________________
>> ParaQ-Developer mailing list
>> ParaQ-Developer@paraview.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/paraq-developer [^]
>>
>>
>>
>>
>> **** Kenneth Moreland
>> *** Sandia National Laboratories
>> ***********
>> *** *** *** email: kmorel@sandia.gov
>> ** *** ** phone: (505) 844-8919
>> *** web: http://www.cs.unm.edu/~kmorel [^]
>>
>>
>>
>
>
>
>


also we could use

SetDllDirectory Function

Adds a directory to the search path used to locate DLLs for the application.

http://msdn.microsoft.com/en-us/library/ms686203(VS.85).aspx [^]


Burlen Loring wrote:
> John Biddiscombe wrote:
>> But unfortunately it's not really paraview's problem. It looks in the place it is told to and finds the plugin, but then undernesath that, windows uses the places it knows about (ie the PATH) to locate the dll's that are pulled in internally by the plugin.
> Currently the loader we are using, Utilities/kwsys/DynamicLoader.cxx, calls LoadLibrary on windows. If it were to instead call LoadLibraryEx we could use the LOAD_WITH_ALTERED_SEARCH_PATH flag to tell it where to look for dependencies.
>
> http://msdn.microsoft.com/en-us/library/ms684179(VS.85).aspx [^]
>
> Looks like LoadLibraryEx is available from win 2k on.
>
>
>


No tags attached.
Issue History
2009-03-04 16:43BurlenNew Issue
2009-03-04 16:48BurlenNote Added: 0015555
2009-03-05 10:55BurlenNote Added: 0015565
2009-03-05 10:55BurlenNote Edited: 0015565
2009-03-11 19:11Ken MorelandStatusbacklog => tabled
2009-03-11 19:11Ken MorelandAssigned To => Burlen
2009-04-08 15:15BurlenAssigned ToBurlen =>
2009-04-08 15:16BurlenNote Added: 0015971
2009-04-08 15:20BurlenNote Edited: 0015971
2009-04-08 15:21BurlenNote Added: 0015972
2009-04-08 15:21BurlenStatustabled => @80@
2009-04-08 15:21BurlenResolutionopen => fixed
2009-04-08 15:21BurlenAssigned To => Burlen
2009-04-15 17:03Alan ScottNote Added: 0016037
2009-04-15 17:03Alan ScottStatus@80@ => closed
2009-05-13 13:45Utkarsh AyachitTarget Version => 3.6
2011-06-16 13:10Zack GalbreathCategory => (No Category)

Notes
(0015555)
Burlen   
2009-03-04 16:48   
By the way, in Applications/Client/main.cxx there is this code:

  QDir dir(QApplication::applicationDirPath());
  dir.cdUp();
  dir.cd("Plugins");
  QApplication::setLibraryPaths(QStringList(dir.absolutePath()));

Probably only helps for client plugins, and only if the plugin dir is $applicationDirPath/../Plugins

Pat
(0015565)
Burlen   
2009-03-05 10:55   
This works on XP sp1

vtkPVPluginLoader.cxx

    // Tell the platform to look in the plugin's directory for
    // its dependencies.
    #ifdef _WIN32
    string pluginDir(file);
    size_t eop=pluginDir.rfind("\\");
    pluginDir=pluginDir.substr(0,eop);
    SetDllDirectory(pluginDir.c_str());
    vtkWarningMacro("Plugin loading: " << file << " from path: " << pluginDir);
    #endif

(0015971)
Burlen   
2009-04-08 15:16   
(edited on: 2009-04-08 15:20)
Fixed by adding the plugin's directory to the shared library search path environment variables.

That is likely a temporary solution. The plugin should have a way of telling the loader what paths to add. For example if the plugin uses a system library not installed in a standard location, that other apps use as well, you don't want to have to copy that file to the plugin dir wasting disk space and making a maintainability hazard. Eg. szip or some such compression utility installed in /opt/szip-vN.M

(0015972)
Burlen   
2009-04-08 15:21   
Fixed by adding the plugin's directory to the shared library search path environment variables.

That is likely a temporary solution. The plugin should have a way of telling the loader what paths to add. For example if the plugin uses a system library not installed in a standard location, that other apps use as well, you don't want to have to copy that file to the plugin dir wasting disk space and making a maintainability hazard. Eg. szip or some such compression utility installed in /opt/szip-vN.M
(0016037)
Alan Scott   
2009-04-15 17:03   
Untested, assumed fixed.