This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: inet string functions
On 6/29/06, jjohnstn <jjohnstn@redhat.com> wrote:
On Wed, 28 Jun 2006, Shaun Jackman wrote:
> On 6/28/06, Jeff Johnston <jjohnstn@redhat.com> wrote:
If we cordone out these functions as optional directories like we do
for other optional functions then it shouldn't harm anything.
Good stuff. It may not be terribly soon, but I'll try to put a patch
together to create a libc/net directory for portable net functions.
> i386-pc-linux-newlib is a little odd in that it requires both Linux
> headers and GNU libc headers to compile. I prefer arm-elf
> (gloss-linux) because it stands on its own.
This is something we need to work on. I would like to make
newlib independent as possible. Adding an additional
platform like arm would definitely go a long way to getting this work
done.
I agree. I don't believe depending on the Linux headers is a terrible
thing. It is the interface we're coding to, after all. But carving out
the dependency on glibc headers would be a big improvement.
You have to remember where newlib sits in the scheme of things. It's
root is an ANSI C Library (note the ANSI and not POSIX) for embedded
platforms. Glibc has been the C Library for native platforms with
full-fledged POSIX support. There are many embedded platforms that don't
even have file systems.
I understand. The embedded system I've been writing for didn't have a
file system until very recently, and used only a small subset of the
functionality of newlib. Since then, we've added a system call
interface and a file system, and I've been trying to adapt newlib to
continue to meet our needs. Glibc is definitely overkill for our
application and depends too much on Linux. newlib is so terribly close
to meeting all our needs that I'd like to see it jump that little gap.
Cheers,
Shaun