[GLLUG] [Fwd: Re: [Firmware] dietlibc for uclibc]

Mike msg at msu.edu
Sat Oct 18 13:08:57 EDT 2008


Below is an interesting email from Rob Landley, a nice fellow who works 
on "Firmware Linux" (http://landley.net/code/firmware/).

Just included it 'cause it was interesting.  :)


-------- Original Message --------
Subject: Re: [Firmware] dietlibc for uclibc
Date: Fri, 17 Oct 2008 16:52:03 -0500
From: Rob Landley <rob at landley.net>
To: firmware at them.com
References: <5c179c7f0810161439j6fc0959fjce72385130632f78 at mail.gmail.com>

On Thursday 16 October 2008 16:39:09 Johannes Klarenbeek wrote:
> he all,
>
> found this amazing libc package a few days ago, thought of you and
> maybe it would be fun to try it out. it would certainly add to the
> size of firmwarelinux!

For a moment, I thought you were talking about klibc, which has been on my
todo list to poke at for a while...

http://kernel.org/pub/linux/libs/klibc/

But I haven't gotten around to it.  For one thing, it's not even trying 
to be
a full glibc replacement the way uClibc is.

> http://www.fefe.de/dietlibc/

I've been aware of dietlibc for years.  I'm also aware why uClibc is 
much more
widely used.  Here's an irc session from the uClibc developers back on
September 16, 2003:

http://ibot.rikers.org/%23uclibc/20030916.html.gz

> 02:13.16  #mjn3#  felix complains that i don't report dietlibc bugs.  so, i
> point out that his "fixed" fputc can write to stdin.  so he adds CANREAD
> and CANWRITE flags and checks for them in fgetc and fputc, but _not_ in
> fread or fwrite
> 02:14.54  #kergoth#  sounds like you're fighting an uphill 
> battle with these people
> 02:15.36  #mjn3#  the dietlibc philosophy seems to 
> be "if it links and it looks like it runs, then it is good enough"
> 02:18.21 # mjn3#  i spent 20 minutes browsing their stdio code yesterday and
> spotted 5  or 6 definite bugs and 4 or 5 other questionable things i didn't
> feel like  taking time to investigate
> 02:19.37  #mjn3#  on the plus side though, i made 
> me check the C99 standard and realize that stdio output behavior when feof
> is true changed between c89 and c99
> 02:20.09  #mjn3#  and while i was 
> looking, i found a site with all the C standard defect reports
> 02:20.24  # mjn3#  so it was 20 minutes well spent
>  02:30.14  #mjn3#  kergoth: the uphill battle i'm fighting is with ulrich
> drepper.  i swear, i don't know how to make things any clearer unless i
> pull out a box of crayons and start drawing cartoons to illustrate the
> problems
> 03:14.54 #mjn3#  sigh... dietlibc's ftell is only 2 lines long, but 
> contains 2 bugs
> 03:15.18  #bug1#  hehe 
> 03:17.24  #mjn3#  but it sure is small...

Possibly it's gotten less thoroughly buggy over the past few years, but 
if so
I hadn't heard about the project's change in direction.  uClibc strives 
to be
small _and_ correct.  klibc strives to be small and simple over everything
else, and sacrifices lots of features to do it.  Dietlibc kind of gets 
caught
in the middle, doing neither well.

Rob
_______________________________________________
Firmware mailing list
Firmware at them.com
http://www2.them.com:8080/cgi-bin/mailman/listinfo/firmware



More information about the linux-user mailing list