Alan Cox writes:
>
> > So we make libc (libm, etc.) subdirectories some place where the
> > linker knows, say, /usr/lib, and put *.o files, one function to
> > a file, in the subdirectories. Each "library" so made would have
> > a common *.o file in which you put all the things that *absolutely*
> > every function in the "library" needs.
>
> Thats how it works. Thats how unix v5 worked even for that matter ;)
>
As Alan says, the standard libc build already splits each C file into lots
of .o files, one per function, which are the bundlued into libc.a. A .a
files is just an archive of .o files, and the linker only links the .o
files it really needs. The actual code segment sizes of most of the elks
system binaries are tiny, as they only link the libc code they need.
Splitting libc up into libsocket, libtermcap etc is only required for
dynamic libraries, which are shared by all the binaries, so have to be
contain all the code for a given library. It is ludicrous to have a shared
library loaded into memory which contains all the socket code, on a system
without networking.
Al
