delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2005/05/30/14:17:44

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
From: "Anonymous" <unknown_kev_cat AT hotmail DOT com>
Subject: Re: dlopen doesn't use LD_LIBRARY_PATH ( was dlopen and cygcheck inconsistency)
Date: Mon, 30 May 2005 14:00:42 -0400
Lines: 31
Message-ID: <d7fk7e$jee$1@sea.gmane.org>
References: <20050530085023 DOT 73565 DOT qmail AT web31714 DOT mail DOT mud DOT yahoo DOT com>
Mime-Version: 1.0
X-IsSubscribed: yes

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019