Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!ANDREW.CMU.EDU!jhh+
From: jhh+@ANDREW.CMU.EDU (John Howard)
Newsgroups: comp.soft-sys.andrew
Subject: Re: why libcx.a (was Problems installing ATK on DECstation 5000)
Message-ID: <4azwn4O00Vs2A4RGMq@andrew.cmu.edu>
Date: 25 Sep 90 21:31:48 GMT
References: <kazkWmm1408JRIX1MZ@birk.cs.chalmers.se>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 30

Christer,

Since this question comes up periodically I'll copy info-andrew in my reply.

Libcx.a is there because the dynamic loader must partition libc.a into
two groups of modules:

  a)  those modules which are loaded with runapp and so are always available.
  b)  modules which are loaded in individual .do files when needed.

Group a is necessary so that global data structures, such as those used
by malloc, are defined only once.  It also functions like a shared
library, since the code segment of runapp is shared across all ATK
applications.  This saves a lot of space.  The dynamic loader knows
about entry points in group a and resolves them as .do files are loaded.

Group b is necessary to keep from putting all of libc.a into runapp,
which would make it outrageously large.  Library modules in group b are
pre-loaded into the .do files which need them.  Makedo accomplishes this
by doing a partial load ("ld -r")  with libcx.a as a library.  If it
were to use libc.a instead then all library modules would be loaded into
all .do files, the equivalent of making group a empty.

This division could be eliminated if the dynamic loader were to do its
own library resolution or if the operating system provides a dynamic
loader which does so.  This would be more elegant but might lead to
other problems - for example the .do files would be less self-contained
and the dynamic loader would be slower and more complex.

John Howard