Re: [Plplot-devel] Peculiar problem with pltcl under Windows - solved

[Arjen M. <arj...@wl...>]

Alan W. Irwin wrote:

>
> I am glad to hear you are getting close, but I am concerned that you have
> to move things around.  That sounds like a really brute force way to deal
> with the issue of finding libraries at run time, and surely there must
> be a better way.
>
> To help clarify the issues, are you talking about the build tree or the
> install tree?  (I don't know whether the windows generator you are using
> even has an install-tree concept, but for the Unix makefile generator, 
> "make
> install" collects all the relevant data, libraries, and executables
> scattered all over the build tree and installs them in standard locations
> in the install tree relative to a prefix that you specify.)
>
I am talking about the build tree and I currently use the makefiles 
generated
using the "NMake makefiles build" option.

What I am trying to do is, to run the examples as a test _prior_ to any
installation (I have not actually come around to that ;)).

> Fortunately, cmake is set up to automatically handle linking both in the
> build tree and in the install tree.  It uses the -L option a lot so that
> libraries get found at link time, and it also uses rpath (at least on 
> Unix)
> a lot so they are also found at run time wherever they are located in the
> build tree or install tree.  I had to do some special configuration 
> (search
> for RPATH in the cmake files) to help cmake do the install-tree rpath
> properly, but it "just works" without any such help for the build tree.
>
> The Unix result is you do not have to set LD_LIBRARY_PATH or move 
> anything
> around to get executables and libraries to work properly in either the
> build-tree (used for tests run with ctest) or the install tree.
>
> I don't understand why you are not getting a similar clean result on the
> windows side of things (especially for the build tree where the build 
> should
> just work automatically so that ctest [which indirectly runs
> examples/tcl/x?? which are shell scripts to run pltcl] can be run without
> any special intervention such as moving anything around).  Obviously, the
> shell scripts themselves are going to be a problem on windows, but you
> should be able to type in those commands, and just have them work, and
> apparently that is not the case.

Windows does not use something like RPATH as far as I know. It uses
a sequence of steps to find the DLLs, and that sequence seems to change
with every edition of Windows, as more insight is gained in the security
issues involved.

For all practical intents and purposes this is what seems to work (at least
with C and Fortran programs):
- The DLL is found somewhere in the directories listed in the PATH 
environment variable
- The DLL is found somewhere in the Windows system directory
- The DLL lives in the same directory as the executable

(Note: not necessarily in that order!)

The problem right now is, that the various DLLs live in different
subdirectories of the build tree (src, bindings/tcl, lib/csa). So an
executable really has to be helped to find all the pieces.

>
> If ctest (or the exact typed out equivalent to run say 
> examples/tcl/x01 to
> bypass the shell scripts) is not working for you without moving libraries
> around, then perhaps it is time for a question to the cmake list to 
> figure
> out an easy way to find cmake-generated libraries at run time 
> regardless of
> whether they are located in the build tree or install tree.

Hm, it may be my mistake not to have used ctest sofar. Instead I have run
the examples in a DOS-box - simply typing the name of the example 
executable.

Will the use of RPATH influence the way someone can distributed an 
application
that uses PLplot or is this limited to the built examples?

Regards,

Arjen