[Paraview] Fwd: [ParaView3-Developer] Fwd: [Still having Problems] Re: Generating a distribution of ParaView with Plugin

[Marcus D. Hanwell]

Berk Geveci wrote:
> Forwading from developers list.
>
>
> ---------- Forwarded message ----------
> From: Burlen Loring <burlen.loring at kitware.com>
> Date: Tue, Mar 24, 2009 at 2:55 PM
> Subject: Re: [ParaView3-Developer] Fwd: [Paraview] [Still having
> Problems] Re: Generating a distribution of ParaView with Plugin
> To: Berk Geveci <berk.geveci at kitware.com>
> Cc: ParaQ Developers <ParaQ-Developer at paraview.org>
>
>
> Rafael,
>
> I am going to assume that, you have all the compiler version/qt
> version stuff sorted out, if you don't what I suggest won't make a
> difference.
>
> I recall having a similar issue. To work around I had to add my
> plugin's bin directory (where it and all of its .dll dependencies
> reside)  to the PATH. When you load  a dll on windows *all* of its
> dependencies must be found, either in the applications run directory
> (in this case that's the ParaView.exe location) or in the PATH. This
> all has to do with the way Windows resolves shared library
> dependencies. Your plugin won't work unless all of the dependencies
> are in the PATH or the same folder as ParaView.exe. In the 3.6 release
> we are adding the plugin's bin directory to the search space
> during/prior plugin load behind the scenes to get around these type of
> issues.
>
> There is a free dependency walker tool that is useful to determine if
> there are any dependencies that you don't know of that may be causing
> your issues.
>
> Burlen
>   

I encountered a similar issue to this when working on the Avogadro
Windows build. There is an alternate solution to this problem - if you
disable manifests for plugins then they do not need to resolve their
dependencies. The solution I found for Avogadro was to add this to our
CMakeLists.txt,

if (MSVC)
    set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /MANIFEST:NO")
endif(MSVC)

As our plugins are built as modules this worked perfectly, Avogadro can
load its Qt based plugins from directories that do not contain
additional DLLs and we do not need to modify the environment. All
reports from users indicate that this approach works well.