Re: Shared Libs

[dsb@goldfinch.cs.duke.edu (Scott Bigham)]

>Every program to use shared libs gets a special set of header files.
>These header files #define every function to something like -
>#define fopen(name,mode)	_dispatch(_lib_stdio,_FOPEN,name,mode)

This doesn't allow for user-created shared libs.  One of the main
reasons we want shared libs so much is so that we can make the Xlibs
shared and cut down the size of some of these X apps.

A variation of this could be made to work, though:  link the program
with a "stub" library full of definitions something like:

  FILE *fopen(const char *name, const char *mode)
    { return (FILE *)_dispatch(_lib_stdio, _FOPEN, name, mode); }

Though it would probably be more efficient for the stub library to use a
jump table that gets filled in by the shared lib manager.

>The loaded functions are kept in memory even after apps quit - however,
>only the functions/modules actually used have to be loaded - and then
>only if the app needs them at run-time.  When a second app needs the
>same function its already loaded.  Modules may be unloaded, reloaded,
>or even moved during run-time, and MiNT may unload the modules as memory
>space becomes sparse.

Hmm.  I don't think we want to make shared libs sticky by default.
Maybe if the file's sticky bit is set.  This also means that the kernel
will have to be aware of the shared lib manager, if Malloc() et al. have
to be able to reclaim memory from it.

As for the issue of the shared lib accessing the program's data space, I
think it comes down to one question:  do we want to be able to take
existing library code and transparently compile it as a shared library?
If not, then we can probably require the library author/maintainer to
arrange for the stubs to pass in the address of any necessary data.  If
so, it will probably mean altering the compiler.

						-sbigham