This is a simple example showing how to create a shared library using ObjectStore.
This example "hides" all ObjectSTore API into a shared library.
The main application then links with this library to do persistent stuff.
The library simply contains a container class for an object that needs to be stored
in the database.

TO run the example:
First type make to create the dynamic shared library called "libtest.so" and the 
main executable called "main" that links with this. Make sure that your
OS_ROOTDIR is set and also your LD_LIBRARY_PATH includes the current directory.

The files slib.cc,slib.hh and schema.cc are used to create the dynamic library.
The main executable is built using main.hh and main.cc.
To run the application type "main". This just creates an object in the database 
and replaces it with another one. 

Note the following:
1. In this example, the schema object file is a part of the shared library. The 
application gets to know the location of the app schema database indirectly via the
shared library. Hence an ossetasp -p on the executable itself will not reveal any
app schema database.
This is only one way of creating dynamic libraries. Typically, we suggest customers
that they build libschemas for each dynamic library and have an actual schema object file
linked statically into the application.
2. In this example the main.hh includes objectstore header files (so as to get in the 
definition of get_os_typespec() for user-defined classes). This is, however, not necessary.
If you want your main application to be "COMPLETELY" hidden from ObjectStore then you can
use the metaobject protocol in your library source files to get the typespec information 
for user classes (ie. the classes for which the library has no information per se).