Re: [RFC] klibc requirements, round 2

[Erik Andersen]

On Fri Jan 11, 2002 at 02:31:50PM +0100, Felix von Leitner wrote:
> > How about responses from the dietlibc and uClibc people on the odds of
> > them being able to port to the remaining platforms?
> 
> I think I can speak for both Erik and myself when I say that we don't
> hate architectures and because of that don't support them.  If we get a
> chance (and maybe a little help from someone who knows those platform),
> we will port our libc to that platform.
> 
> Sadly, I don't have the deep pockets to buy myself a hardware lab with a
> VAX to port my libc to it.  So I (and Erik, too, obviously) would need
> at least an account on one of those boxes, with gcc, binutils, strace
> and gdb installed.

Fully agreed.  Porting libc (diet or uClibc) is an issue of
hardware access, access to the instruction set docs for the arch,
access to a gnu toolchain, and (the biggest issue) an issue of
time and motivation.

> In my eyes that is a waste of time, really.
> But it's your time, so don't let that stand in your way ;)

I agree here.  dietlibc is GPL.  uClibc is LGPL.  I think they
both address the problem space pretty well.  Felix and I are
both willing to accept patches.

Lets look at it the other way...  Suppose you start making a
separate klibc.  You skip/eliminate a ton of stuff and next week
someone complains that it's missing, say, the pivot_root syscall.
So you add it.  Then the week after, someone complains that you
are missing varargs.  So you add that too.  Pretty soon, someone
will complain about how printf feature foo is missing, and they
just _need_ SuS2 wordexp compatibility, etc, etc.  Trust me when
I say you are on a very slippery slope, with a awful lot of
redundant work ahead of you.  If you want to pursue it, thats
fine, and I'll even help you a bit.  But I think that soon
enough, you will converge on what dietlibc and uClibc already
have.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--