Re: hardcode_libdir, rpath and DLLs

[Brian Dessent]

Robert Szeleney wrote:

> Unfortunately, PE DLLs don't support this --rpath option. Is there any
> way to tell libtool to use something different for this?
> 
> Probably using LD_LIBRARY_PATH. Though I think that this will not
> really work, because whenever you execute glib-genmarshal one would
> have to set this path. (Inside the make process this may not be really
> a problem, but when executing directly from the shell no one has set
> this path yet).
> 
> How does cygwin deal with this? Does this even work on cygwin?

Win32 doesn't have any such notion of LD_LIBRARY_PATH, so that is not an
option.  The DLL search rules are very simple, I think it's essentially
1. current working directory, 2. $PATH, 3. Windows system directory. 
There may be other obscure modifiers too.  The full search order is
documented on MSDN under the LoadLibrary() function I think.

I suspect the right way to handle this would be to use "libtool
--mode=execute" to run the binary, and that should either set the
working directory to the dir where the DLL lives or set $PATH.  Or maybe
libtool uses a wrapper script for the binary.

[ Note that Cygwin does actually support LD_LIBRARY_PATH but only when
doing dynamic runtime loading of a library with dlopen(), but it can
only do this because at that point Cygwin is fully in control of things
and can fake it.  When simply calling on the operating system to load a
binary (in the case of ./foo) there is no way to influence the DLL
search process since that is done by the Windows dynamic loader. ]

Brian