Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-Id: <199912212035.OAA10928@hp2.xraylith.wisc.edu>
To: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: SUMMARY: Known issues with gnuwin32 development tools of year 1999 
In-reply-to: Your message of "Tue, 21 Dec 1999 15:28:11 EST."
             <19991221152811 DOT A5107 AT cygnus DOT com> 
Date: Tue, 21 Dec 1999 14:35:10 -0600
From: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>

[ Only following up in Cygwin mailing list ]

Chris Faylor <cgf AT cygnus DOT com> writes:

> Just to add a little bit more info, Mumit submitted a patch which
> probably will fix the problem but the patch uses malloc for temporary
> storage.  I've recently been bitten by the use of malloc in
> initialization code so I've been futilely trying to think of some way
> around this.  It's probable that Mumit's use of malloc won't really
> cause a problem but I'd like to avoid it if I can, so I've been letting
> this simmer in my unconscious mind for a while to see if it comes up
> with something interesting.

Before I forget, I do have a patch that uses malloc for dynamic loading,
but keeps event-based synchronization for the "normal", ie., link-time 
loading. Is that acceptable? If so, I'll dig it out ... 

With this, you can let it simmer while allowing both static and dynamic 
loading to work ;-)

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com