Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!ames!vsi1!daver!bungi.com!news
From: culberts@hplwbc.hpl.hp.com (Bruce Culbertson)
Newsgroups: comp.sys.nsc.32k
Subject: Re:  Yeargh! Estdio is driving me insane!
Message-ID: <9103061751.AA02839@hplwbc.hpl.hp.com>
Date: 6 Mar 91 17:51:33 GMT
Sender: news@daver.bungi.com
Lines: 23
Approved: news@daver.bungi.com

My two cents worth...  I am basically in agreement with Jordan on
stdio/estdio.  No one wants to keep choosing between two stdio's
on a daily basis.  I could see having a small stdio available for
compiling a few of the most fundamental /bin commands -- cp, cat,
mkdir, etc.  That way you could make a really small emergency file
system.  But once that was done (if it is even that important), I
personally would never use the small stdio again.  Someone else,
though, might always want to use the small stdio.  It would be nice
if we had simple, fool-proof, scripts for installing each.  But I
do not think it's necessary that the two stdio's be able to co-exist,
each equally accessible on the same file system.

> (I.E. you can't extract libc.a into a temp directory, extract the compiled
> stdio.a on top of it, then repack the whole mess into a new libc.a)

I still am not clear why this doesn't work.  Do some commands and
non-stdio library routines make assumptions about data that should
really be private to stdio?  Do they call routines which should really
be private to stdio?  Maybe we could cajole the original authors
of estdio to clean this up.  If we fix it ourselves, then it will
be hard to merge updates into our sources.

Bruce