Delivered-To: listarch-cygwin AT sourceware DOT cygnus DOT com
Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
X-Authentication-Warning: modi.xraylith.wisc.edu: khan owned process doing -bs
Date: Fri, 12 Feb 1999 17:00:40 -0600 (CST)
From: Mumit Khan <khan AT xraylith DOT wisc DOT edu>
To: "Brimhall, GeoffreyX L" <geoffreyx DOT l DOT brimhall AT intel DOT com>
cc: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: newlib and glibc compatibility
In-Reply-To: <7FD5C79AD680D211AC4100A0C96B501C78F638@ORSMSX49>
Message-ID: <Pine.SUN.3.93.990212165331.19239C-100000@modi.xraylith.wisc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 12 Feb 1999, Brimhall, GeoffreyX L wrote:

> How close are newlib and glibc ? Is there any chance that at some point
> newlib will implement glibc and so be able to use it's headers ?

Ah, the annual question ;-) Newlib and glibc are *very* different. As for
Cygwin using glibc instead of newlib, it's not going to happen. Search the
mailing list for more info.

> This would help porting linux code based on glibc.

What is "Linux code based on glibc"? It's either POSIX (portable) or not
(non-portable); if it's portable, it's usually a simple port, other than
possibly working around newlib bugs and implementation limitations, and
various platform specific issues (file system layout, authentication
methods, so forth and so on).

People who write code that depends on glibc either know what they're doing
or/and deserve what they get.

Instead of trying to get glibc to work with Cygwin or vice-versa, a much
more productive approach is to contribute to fill in the missing pieces 
in newlib.

Regards,
Mumit