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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
