dlopen doesn't use LD_LIBRARY_PATH ( was dlopen and cygcheck inconsistency)

[Anonymous]

> this issue is still un-resolved. Contrary to what
> cgf says, dlopen doesn't care about LD_LIBRARY_PATH
> while opening dependent DLLs of its argument. It opens
> the DLL if the depedent DLLs are found in the $PATH.
>
Your keyword is dependent.

When one dll depends on another in windows, it uses window's built-in dll 
locator. IIRC, on Linux the linker stub (.sa file) uses dlopen to load the 
shared library (.so file). This means that anything, either program or 
another library, will end up accessing the library through dlopen. On Cygwin 
the stub (.dll.a) does not open the library through dl_open, but rather 
window's internal mechanism, which is in some ways similar to dlopen, but is 
not aware of LD_LIBRARY_PATH. Since Cygwin's libraries load each other (and 
the windows libraries too) via the stubs, the OS will search for the 
libraries required by the one you are trying to dlopen, without paying 
attention to LD_LIBRARY_PATH.

So Cygwin will use LD_LIBRARY_PATH to find 'c.dll' if needed, but Window's 
internal mechanism to find 'b.dll'. This is due to the design of Windows. 
This is a non-issue and is WONTFIX.

For your reference this is how windows looks for dlls:
1. Directory from which app loaded (executable directory)
2. Current directory (can be overridden with an API call to SetDllDirectory)
3. System directory
4. 16-bit system directory
5. Windows directory
6. Directories listed in the PATH environment variable
 



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/