This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: Confirming porting strategy
On Fri, 2005-09-23 at 14:35 -0400, Daniel Jacobowitz wrote:
> What's missing from the rest of your message, completely, is the
> explanation for "we want to use glibc". Glibc is a hosted,
> POSIX-conformant C library. Its main advantage over other C libraries
> is how thorough, complete, and conformant it is. If you don't want a
> whole POSIX interface, why are you switching away from newlib?
When we do our linux compatibility environment, we obviously want glibc.
The question here concerns the native-mode environment.
The main issue with newlib is that it appears to be dead. The last
tarball of newlib was done in 1994. There have been some changes since
then (e.g. C99).
Stepping beyond that, there is a lot of common function that we want to
support. For example, I can't think of *any* reason why we would want to
deal with more than one NLS implementation (or carry multiple copies of
the supporting data files). The drift would be horrible.
The problem is that Coyotos isn't a non-hosted environment. It's a
hosted environment that isn't hosted on POSIX. In an ideal world, we
would take a razor to glibc, push all of the POSIX stuff to one side of
a line somewhere, all of the generic stuff to the other, and just turn
off the POSIX stuff.
I do understand that non-POSIX portability is not a GLIBC design
objective today. From a purely selfish perspective, this is unfortunate,
but unless there is a POSIX-motivated advantage to establishing greater
modularity, I think the glibc maintainers have quite enough to do
already and I'm not inclined to try to push a diversionary effort. If it
turns out that changes in the tree improve matters for purely POSIX
builds, my sense is that we should propose them.
shap