Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-developers-unsubscribe-archive-cygwin-developers=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>,
	<http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Message-Id: <199908311342.IAA14819@mercury.xraylith.wisc.edu>
To: Chris Faylor <cgf AT cygnus DOT com>
cc: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: WARNING: previous dlopen of %s wasn't correctly performed 
In-Reply-To: Your message of "Tue, 31 Aug 1999 01:19:25 EDT."
             <19990831011925 DOT A9493 AT cygnus DOT com> 
Date: Tue, 31 Aug 1999 08:42:16 -0500
From: Mumit Khan <khan AT xraylith DOT wisc DOT EDU>

Chris Faylor <cgf AT cygnus DOT com> writes:
> Can anyone tell me what this error message signifies?  I've got it coming fro
> m dlopen
> but I'm too tired to figure out why.
> 

If you're using dlopen, I may know have a clue; otherwise, sorry.

Point your debugger to DllList::recordDll and check then "buf" and
_dlOpenedLib variables and that should provide a clue.

The problem is quite possibly in DllList::recordDll, and usually has 
to do with the fact the the DLL name given to dlopen doesn't match the 
name Windows returns via GetModuleFileName later in recordDll. Usually
the problem is in case mismatch, and that should have been fixed by the 
following patch:

Sat May 22 19:03:47 1999  Mumit Khan  <khan AT xraylith DOT wisc DOT edu>

	* dll_init.cc (DllList::recordDll): Forkee must reload dlopened
	DLLs. Also use strcasematch, not strcmp to compare file name.

The other issue may very well have to do with symbolic links, however
it does appear to be taken care of in dlfcn.cc:get_full_path_of_dll. See
get_full_path_of_dll and check_access in dlfcn.cc for how a DLL name is 
looked up. 

Regards,
Mumit