X-Spam-Check-By:	sourceware.org
Message-ID:	<4473CF07.9090201@kleckner.net>
Date:	Tue, 23 May 2006 20:12:07 -0700
From:	Jim Kleckner <jek-cygwin1 AT kleckner DOT net>
User-Agent:	Thunderbird 1.5 (Windows/20051230)
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: 1.15.19 dlopen() dies with no dlerror()
References:	<Pine DOT GSO DOT 4 DOT 58 DOT 0604111406110 DOT 24175 AT sue> <4472AF3B DOT 2050300 AT kleckner DOT net> <4473B387 DOT 2020905 AT kleckner DOT net> <4473C5C9 DOT 50104 AT cygwin DOT com>
In-Reply-To:	<4473C5C9.50104@cygwin.com>
X-IsSubscribed:	yes
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

Larry Hall (Cygwin) wrote:
> Jim Kleckner wrote:
>> Jim Kleckner wrote:
>>> Michael McKerns wrote:
>>>> Yes, yes...  I've not given you enough information...
>>>> ...
>>>> See:
>>>> http://cygwin.com/cygwin-ug-net/dll.html
>>>> http://cygwin.com/faq.html#faq.programming.dll-relocatable
>>>>   
>>> I'm seeing a similar problem with python and 1.5.19 and also tried 
>>> the snapshot of 22-May.
>>>
>>> CYGWIN_NT-5.1 kleckner2 1.5.20s(0.155/4/2) 20060522 00:51:23 i686 
>>> Cygwin
>>>
>>> A simple test case doesn't fail in dlopen().
>>>
>>> My code is not simple but has been working prior to the most recent 
>>> update (which also updated python and other packages).
>>> A downrev of python does not make the problem go away.  If I downrev 
>>> cygwin, I get complaints about missing entry points.
>>>
>>> What do you recommend as the best way to isolate this?
>>
>> I tried using "prev" with setup.exe but that didn't make the problem 
>> go away.
>>
>> A simple test case with python access to a trivial function works 
>> fine (can supply if anyone wants).
>> The complex dll that used to work simply doesn't return from dlopen.
>>
>> I downloaded the 20060522 snapshot with debug symbols to get a 
>> backtrace with GDB.
>> GDB says there is a seg fault and somehow this is preventing any 
>> information from reaching dlerror().
>> Without the dlerror() info, it is hard to figure out what needs to 
>> change with the dll.
>> It appears that some constructors are having trouble.
>>
>> Let me know if there is some single stepping that could be helpful.
>> [snip]
>> (gdb) bt
>> #0  0x610b1ff8 in pthread_key_create (key=0x6622f8, destructor=0) at 
>                     ^^^^^^^^^^^^^^^^^^^
> Known issue already fixed in the Cygwin snapshot and in GDB's CVS.  This
> is not fatal.  Just continue until you stop seeing this complaint.
>

As noted above, this was tested using snapshot 20060522. 
Should that snapshot have the fix you mention?  If it should, then this 
problem still exists in that snapshot.
If not, then which one should I test?

Thanks - Jim

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