Re: size of XEmacs binary under Sparc/Solaris 2

Some points on this thread: 1. The output of ldd is unrelated to the on disk size of an xemacs binary except to illuminate that which is NOT statically linked. 2. Debugging information is huge. A trivial thing like a file scope integer variable becomes a name-mangled global so that a debugger can find it. 3. Everything will in the output of ldd will be mapped into a process address space at runtime. Synbol resolution happens on demand and is a simple traversal of the dependencies stopping with the first occurence. So, for example, ldd reports multiple libX11.so.nn dependencies. The first call to XOpenDisplay() will via the runtime linker land in the first libX11.so.nn reported by ldd. The other versions just sit there occupying memory. This phenomena is not a huge problem until the signature of XOpenDisplay changes ;-) All this stuff is very well documented in the "Linker and Libraries Guide". Solaris 2.7 and beyond will support finer control over symbol binding. You can stop reading now, unless you want a little more detail on runtime linking: Objects are compiled such that calls to unresolved function references are actually calls into a procedure linkage table (PLT). The PLT is initially filled with calls into the runtime linker. The runtime linker finds the desired function and re-writes the PLT entry so that future calls are "direct".