libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: hardcode_libdir, rpath and DLLs


From: Robert Szeleney
Subject: Re: Re: hardcode_libdir, rpath and DLLs
Date: Thu, 27 Apr 2006 12:11:45 +0200


Hi Brian!

>>> 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?

>>>
>>> Robert

>> 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.

>> Brian

Sorry, I should have included a reference to following posts:

http://lists.gnu.org/archive/html/libtool/2006-04/msg00047.html
http://lists.gnu.org/archive/html/libtool/2006-04/msg00027.html

I'm actually porting libtool to SkyOS which mostly works already. So I'm not running windows/cygwin, its just that the SkyOS executable format is PE/DLL, thats way I'm refering to cygwin in the last post.

>> [ 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. ]

Actually SkyOS respects the LD_LIBRARY_PATH variable when loading an executable.

Thanks!
Robert!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]