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

- Raw text -