Scorecard:
	Global Funcs	Weak Funcs	Global Data 	Weak Data.
	------------	----------	-----------	----------
(For comparison)
SVr4 libc	458	   215		   70		   8

2/13/94:	313	   112		   40		   2
2/17/94:	336	   120		   62		   6
******************************************************************
2/26/94:

	SVr4 Emacs runs.  It has some warts still, because of missing
emulator functions and ioctls that have not yet been added, but it comes
up with the correct file on the screen, and you can edit the file and save it.

	Added some patches from Al, sigaction and sleep have been
tested.  Provisions have been made in sigaction so that it is possible
to use the library both on SVr4 and on linux systems.

	The various getpw* functions have been added to the library.

	The socket() function has been added to the libsocket.so
library, but it fails because some arguments need to be translated.  I
need to hear from Mike before I know how best to fix this.

2/18/94:

	Fixed a number of bugs, in fork(), waitpid(), ctype and modf.
Still some left, I am afraid, but I can run larger and larger binaries
now.  Sleep and sigaction are now in the library, but there is no
sigaction syscall in the emulator yet.  Note you can NOT simply map
this to the linux sigaction, since the elements of the structures are
in a different order.  Still, as far as adding new functions to libc is
concerned, it feels like we are on the home stretch.

2/17/94:

	Locale added, from libc-linux.  Not very fancy, but it works.
Kind of limited in terms of features - multi-language/international
stuff will need a little work here.  Time stuff added, seems to work
fine.  The SVr4 "ls" binary now works flawlessly, and does not have
any more missing symbols.  The SVr4 "vi" prints out all kinds of
strange crap to the screen.  This may be normal :-).  Actually, it indicates
further bugs somewhere.

	Major bug found in __pipe.S, and fixed.  Minor bug in
__makedev fixed.

	Remainder of exec* functions added.

2/16/94:
	Added functions for __major, __minor, __makedev, added
	weak symbols for _flsbuf and _filbuf, and added a hack workaround
	so that the program runs correctly if it uses setlocale.

	New directories, locale and time, but these are not used because
	they do not yet interface properly with the rest of the library.
	Once they are fixed, they can be used.  The libc-linux
	implementation really sucks anyway, I will see if netbsd has
	something better.

2/13/94:
	Got a bit further - grepped the stdio code for bugs involving
the precedence of & and ==, and found 4 more.  Added getdents,
and the dirent code for readdir, opendir, etc, etc.

	Spent some time making library conformant to SVr4 wrt weak
symbols.  A number of functions apparently need these.

	Starting work on libsocket and libnsl.  Finding suitable
source code could be a problem here, but it appears as if SVr4
implements much more of the networking in user space.  Both Wyse and
linux implement these functions in kernel space, so we can probably
tap into the Wyse TCP stuff and come up on top.  It will make
implementation relatively easy.  I do not know at all about the ibcs2
libnsl - most of the entry points are foreign sounding to me.

2/12/94:

	Many new functions required by SVr4.  Some are stubs that
are not yet handled by ibcs2 emulation, but this is OK.  A number
of bugs were fixed, and the number of applications that do the
right thing is expanding.  Still many missing functions, and still
a few bugs here and there.

2/6/94:

	Much closer now.  I can build a sharable library under SVr4,
and it seems to work just fine for simple test programs.  Dynamic linker
would seem to be functional and stable, so hopefully the only thing
left at this point is to debug the rest of libc.

	Dynamic linker features:

	* Compatible with SVr4 (i.e. the libc.so.1 will run under SVr4).
	* Supports SVr4 ldd mechanism.
	* Fully PIC.
	* Supports .init and .fini sections (used for C++ constructors/
	destructors, and perhaps other things).

	Misfeatures:
	* Must be compiled under SVr4 because of lack of shared library
	support in gnu utilities.
	* Expects to be able to use mprotect to make text pages writable
	for dynamic linking.  It also expects to be able to set the
	text pages back to R/O after it is through.  The kernel loader
	loads everything as R/W so this is not a problem, and once we
	get a real mprotect, it should work without any changes.
	
	I still have problems with a static linked binary from SVr4
dumping core.  This would point the finger at the kernel loader and
the ibcs2 emulation library.  I have gone over the loader pretty carefully,
so it should be OK.  The ibcs2 emulation library would seem to be a likely
culprit.

	There are a lot of bugs left in the rest of libc.  Undoubtably
with time this will get cleaned up - right now it is pretty easy to
find applications that misbehave.  Some problems may also be with ibcs2.

1/30/94:

	Uploaded a new version.  The ELF stuff I did should not affect
you very much, so I would not worry about that, however, I have
modified the sysdeps directory quite a bit.  A number of files were
deleted because they apparently do not call legitimate functions in
iBSC2.  Also I changed the level of leading underscores in some cases
- if these changes give you problems, let me know, and I can add them
back and figure out a different way of doing this.

	When I build an ELF library, I basically link every .o file
that is built into one executable.  Thus I am sensitive to undefined
functions - it is possible that with COFF, you do not really notice
this as much because some of these functions are never pulled out of
the libraries.

	My own status report: I get the thing to link, and it more or
less runs.  The problem is that the GNU ld does not supply information
for dynamic linking yet, so the non-PIC library is useless.  I will
have to work from now on with SVr4 :-(.  Anyway, at this point, it
should all compile properly, but I may need to fiddle with things to
get the PIC stuff right.  Slow but steady progress I guess.  My kernel mods
to support an ELF dynamic linker seem to be working.

**************************************************************************

	I took the library that Al assembled, and I started hacking
it.  I fixed a few bugs here and there, and re-arranged things a
little bit.  The Makefiles all reference Makerules and Makeconfig on a
relative basis instead of the paths that Al had used before.  I personally
prefer to have things that will build whereever they are unpacked.

	To build you type one of the three:

	make COFF=true
	make ELF=true
	make AOUT=true

The a.out library is useful for debugging but the shared library that
is generated is not of much use.  The ELF is what I work with, and the
parameters for COFF are what Al used before I picked this up.

	I took the liberty of filling in a complete include/ tree that
is sufficient to compile the entire library.  I did this so that we
could ensure that under no circumstances would there be any kind
accidental inclusion of header files from linux itself in cases where
it was not appropriate, and also because I will probably build run
time libraries for SVr4 under SVr4, and I would feel much better if
the whole thing were self contained.  In particular, we reduce the
possibility of picking up incorrect versions of errno.h, signal.h,
etc.

	I changed a number of the syscalls from C code to assembly
because it turns out that we do not need to be concerned with varargs
types of functions (I think) - if I am wrong, we can restore it.
These should be tried I guess.

	It is possible that I broke something when I did all of this
shuffling around, and if this is the case, I apologize.

	Finally, some small test programs that I have tried both under
SVr4 and linux seem to work.  I have tested stdio lightly via printf,
and after I fixed one small bug it seems to work fine (I have tried
simple things like open(), printf(), getpid(), and a few others).  My
thinking is that the whole thing can be tested as a static library
with libc, so that you do not have to worry about shared libraries and
all that.  The debugging should go quickly, I would think.

	Ultimately I may have to change some definitions in a few
places for SVr4, but we will cross that bridge when we come to it.
Many of the affected files are merely stubs anyway, so changes in
datatypes could be ignored.

-Eric
