[Top][All Lists]

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

Re: cygwin/mingw: do not lie about hardcoding

From: Bob Friesenhahn
Subject: Re: cygwin/mingw: do not lie about hardcoding
Date: Wed, 6 Sep 2006 08:51:13 -0500 (CDT)

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 Friesenhahn
GraphicsMagick Maintainer,

reply via email to

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