Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-ID: <3D6CAE06.7080805@netscape.net>
Date: Wed, 28 Aug 2002 07:03:34 -0400
From: Nicholas Wourms <nwourms AT netscape DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cygwin-developers AT cygwin DOT com
Subject: Re: A quick note on <newlib.h>
References: <000201c24e27$ffa0bb10$6132bc3e AT BABEL> <20020828003122 DOT GL16631 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Christopher Faylor wrote:

>[SNIP]
>

>This is one of the reasons that I'm getting sick of our dependency on
>newlib.  I've asked that cygwin be taken into account when making
>changes like this but, the last I heard, the newlib guys were stalled
>trying to accommodate my request since the two year old gcc cross
>compiler that they insist on using is no longer able to build cygwin.
>
Sneak into their office and "assist" them in an upgrade :-).  Or better 
yet, put 'em in thier place via a live demonstration showing how wrong 
they are.

>
>It's easy enough to add another include path to cygwin but I'm not sure
>that I want to do that.  I think, instead, I'm going to start thinking
>about how we can eliminate our dependency on newlib.
>
I know this has been talked about to death, but in light of your 
comments I feel it is appropriate to revisit the matter.  Although not a 
trivial task, perhaps we should seriously consdier switching to glibc? 
 After all, it is the gnu standard, yet another RedHat (cygnus) hosted 
project, and seems, athough this isn't currently being exercised,  more 
apt to handle multiple platforms with varied configurations.  Plus, it 
seems to be lightyears ahead of newlib in the various levels of Posix 
and SUS compliance.  Not only that, but the documentation is *so* much 
more complete.  Admittedly it is bulky, but who says we have to use 
everything?  IIRC, most of the bulk is due to massive i18n support, 
which is, for the most part, handled by other external libraries.  I 
know what you're thinking, but before you write me off as a k00k, take a 
moment to considier the pros and cons.  Just my opinion though, so feel 
free to disagree.

Cheers,
Nicholas