Re: glibc 2.1.94

[John Kennedy <jk at csuchico dot edu>]

On Mon, Sep 18, 2000 at 06:33:03PM -0700, Ulrich Drepper wrote:
> I am still extremely disappointed about the participation.  I got one
> or two reports about a successful compilation and bug reports from
> perhaps six people outside the developer group.  This is not enough
> evidence that things are working properly.  I repeat this: you can
> test glibc without installing it.  Just compile and run `make check'.
> The only thins you need is diskspace (about 350MB on x86, more on RISC
> platforms), working tools (make, gcc, binutils), and either time or a
> fast machine.

  If you want an incomplete semi-success report with glibc 2.1.93 then
I can say that I've had some luck with it.  So far my experiences have
been very chicken-n-egg.

  linux-2.4.0-test* doesn't seem to get along too well with glibc-2.1.3
headers (*1), so I started trying out glibc-2.1.93.  After adding
an extra disk for space, then I get into the fun dependency wars.
glibc-2.1.9x wants more modern gcc (currently using egcs-20000828).
A handful of programs really don't like the modern gccs (only seemed
to like gcc-2.7.2 generation, and haven't been updated since then).
Lots of porting, tweaking, etc.  The compiler itself is causing some
problems with some of the builtin functions and the way people kludge
prototypes (all the #defines of bzero() into memcpy() for example).

  In any case, so far I've looked at about ~37 bits of software with
some success in making progress to a usable whole.  The typical, well
ported program generally doesn't seem to have a problem.

  I've just grabbed -2.1.94 and I'll start kicking on it.


  *1:	This seems to be generally bad interaction with <linux/fs.h>
	with a small subset of programs that need actual kernel
	headers.  They had kludges for 2.2.17 generation headers
	but the same program compiled against 2.4.0 headers have
	problems.