Re: cygwin/mingw: do not lie about hardcoding

[Bob Friesenhahn]

On Wed, 6 Sep 2006, Eric Blake wrote:
> > This is a new TODO item.
> >
> > The w32 support in Libtool currently lies about their hardcoding
> > capabilities by setting hardcode_libdir_flag_spec to a nonempty value.
> > This makes ltmain think that it can hardcode this way.
> >
> > More generally, the search order is:
> >
> > - the directory of the current executable,
> > - the current directory,
> > - the w32 system directory (GetSystemDirectory returns this),
> > - the w32 directory (GetWindowsDirectory returns this),
> > - directories in PATH.
>
> But that is the search order for native windows .dlls and LoadModule.
> Cygwin dlopen(), on the other hand, strives for Linux compatibility, and
> has tricks up its sleeve to override the Windows default search path with
> one that is more similar to Linux shared library lookup.  So I'm not sure
> whether this TODO is mingw only, instead of cygwin/mingw.

Are you saying that Cygwin supports LD_LIBRARY_PATH?

Cygwin programs are obviously originally located using Cygwin-supplied 
rules (due to the Unix-style shell).  Does Cygwin also handle 
locating/loading all of the DLLs that the application depends on? 
Doing so would require special static startup ("crt") code for Cygwin 
applications which knows how to evaluate dependencies and load DLLs 
since otherwise normal Windows rules would apply.  My understanding is 
that most (all?) Cygwin code resides in a single DLL.  The fact that 
Cygwin installs DLLs in the executable 'bin' directories strongly 
suggests that there is no special startup code and that Windows 
handles the DLL loading using its own rules.

Lastly, does libtool now use Cygwin's dlopen()?

Bob
======================================
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/