Ah! I finally have a progress bar that doesn't stall the build!
- pipe size in Linux is only 8*512=4096 bytes
- pipe size is not setable
- when the feeding process spits out data faster than the eating
process can read it, then the feeding process stalls after 4KiB
of data sent to the pipe
- for us, the progress bar would spawn a sub-shell every line,
and the sub-shell would in turn spawn a 'date' command.
Which was sloooww as hell, and would cause some kind of a
starvation: the pipe was full most of the time, and the
feeding process was stalled all this time.

Now, we use internal variables and a little hack based onan offset
to determine the elapsed time. Much faster this way, but still
CPU-intensive.

Give preference to target-optimised functions over glibc's ones,

which in turn ahave precedence over generic ones.

--- uClibc.orig/libc/Makefile	2005-07-20 08:10:44.000000000 +0200

+++ uclibc/libc/Makefile	2005-07-28 13:33:40.000000000 +0200

@@ -59,7 +59,7 @@

 	$(AR) dN 2 $(LIBNAME) $$objs && \

 	$(AR) dN 2 $(LIBNAME) $$objs

 	@for objfile in obj.signal \

-	                obj.string.generic obj.string.$(TARGET_ARCH) obj.string \

+	                obj.string obj.string.generic obj.string.$(TARGET_ARCH) \

 	                obj.sysdeps.common obj.sysdeps.$(TARGET_ARCH) ; do \

 		if [ -e $$objfile ] ; then \

 			echo $(AR) $(ARFLAGS) $(LIBNAME) $$objfile ; \