Herb,
In your summary of the D0 meeting, you say:

>4.  TObject issues.
>One potential disadvantage of deriving d0_Object from TObject is the 
>physical coupling issue. How much ROOT code would be pulled into all D0 
>executables?  After the meeting Scott Snyder did a test where he >compiled and linked a simple program with a simple TObject class.  The >result was an executable with a size of 11.5 Mb drawn from 274 source >files, i.e., a significant fraction of all ROOT code.  The same test >with d0_Object gave an executable size of 50 kb drawn from five source >files.  It is clear that for deriving d0_Object from TObject to be >feasible, some work would have to be done to decouple TObject from the >rest of the ROOT system.

In the Makefile used by Scott to link this toy program,
 ***ALL Root object files are explicitely linked !!!
We provide shared libraries, see list below with their
respective size (this on Linux). The 11Mbytes claimed by Scott
is the total size of the Root system (not large after all!!).
A normal application links with the shared libs resulting
in very small executable modules. I have taken your toy
program and linked it with the "default"list of shared libs
suggested in the Root example Makefile (see code below)
ROOTLIBS  = -L$(ROOTSYS)/lib -lBase -lClib -lCint -lMeta -lCont \
            -lGraf -lHist -lGraf3d -lFunc -lUnix -lPostscript \
            -lNet -lZip -lProof -lMinuit -lTree
The resulting executable module is only 6.2Kbytes (6279 bytes).
I am listing below the size of all executable modules
in the $ROOTSYS/test directories. These test programs
play with many Root classes and can be executed in batch
or interactively:

-rwxr-xr-x   1 brun     cr   71167 Sep 14 20:27 Event
-rwxr-xr-x   1 brun     cr   55479 Sep 14 20:27 guitest
-rwxr-xr-x   1 brun     cr    9080 Sep 14 20:27 hsimple
-rwxr-xr-x   1 brun     cr    8212 Sep 14 20:27 hworld
-rwxr-xr-x   1 brun     cr   14095 Sep 14 20:27 minexam
-rwxr-xr-x   1 brun     cr   27640 Sep 14 20:27 tcollex
-rwxr-xr-x   1 brun     cr   12562 Sep 14 20:27 tstring
-rwxr-xr-x   1 brun     cr   21056 Sep 14 20:27 vlazy
-rwxr-xr-x   1 brun     cr   66075 Sep 14 20:27 vmatrix
-rwxr-xr-x   1 brun     cr   47807 Sep 14 20:27 vvector

//=========== The toy program used. 
// this shows how to start a simple application in batch.
#include "TROOT.h"

int main()
{
   TROOT root("hello","Hello World");
   TObject *obj = new TObject();
   return 0;
}
//==============================================

The Root executable itself is small (about 100Kbytes).
The memory requirements to run the standard Root ranges
from 3Mbytes to typically 8->10 Mbytes, ie about the same
size as PAW and this including dynamically allocated
memory. As you have found the TOTAL size of all the
Root classes is around 11 Mbytes.

We have dependencies (essentially the TROOT object itself).
These dependencies have been carefully evaluated regarding
their pros and cons. We have included in the TROOT object
the initialisation for very frequently object classes,
including the TMinuit and TPostscript class to avoid painful
initialisation in the users code. In a sense, it is a tradeoff
between simplicity of use and memory penalty.
Executable modules built with Root are much smaller
than the equivalent modules built with the Cernlib
libraries such as libPacklib and libPawlib.

We are perfectly aware of some undesired dependencies
in the package. We want to remove them gradually.
I have discussed with the graphics group, this afternoon,
the worst case in Root where we have a circular dependency
between TH1 and TGraph classes. Such dependencies are due
to historical developments.

Using Root, one must be careful in structuring the classes
correctly when building the CINT dictionary. Typically
classes processed by one rootcint command are put in
the same c++ file and linkers are not clever enough to realize
that there is may be some unused code in the corresponding
object module. Here again, developers have to make a
compromise between classes logically belonging together
and therefore assigned to the same package and be careful
not to generate unnecessary dependencies.

Rene