jhh+@ANDREW.CMU.EDU (John Howard) (09/26/90)
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 Howardbernerus@BIRK.CS.CHALMERS.SE (Christer Bernerus) (09/26/90)
Thanks John for taking time answering my question. From your answer I understand that libcx.a contains all modules that might be preloaded into any .do module. Now, from the Imakefile I understand that, when creating libcx.a, the module /lib/crt0.o is explicitly included into libcx.a. This module is not originally a member of /lib/libc.a (at least not on the DEC Mips machines). I have experienced that, when crt0.o is included, it won't be possible to compile atk/basics/common/environ.do. If, however, crt0.o is deleted from libcx.a, environ.do compiled wothout error. Is there something that breaks if I delete crt0.o from libcx.a forever. I haven't compiled all of ATK yet, so I haven't tested. Chris. ------------------------------------------------------- Christer Bernirus ! E-mail: bernerus@cs.chalmers.se Chalmers University of Technology ! Phone: +46 31 721000 Department of Computer Science ! Ham radio: SM6FBQ 144.3 MHz S-412 96 Gvteborg, SWEDEN
ajp+@ANDREW.CMU.EDU (Andrew Palay) (09/27/90)
I can't understand why things from crt0.o would ever be in libcx.a. My understanding of crt0.o is that is is used only at startup and thus is not needed by dynamically loaded modules. The Imakefile does add it during the process of building libcx.a but then should remove all symbols defined by crt0.o in the next line. I believe that crt0.o is added to libcx.a to keep the next line from producing errors about files that it can't delete because they are not there. Thus removing the addition of crt0.o from the building of libcx.a should be fine assuming that ar doesn't give any fatal errors when asked to remove files that are no there. In fact this problem is better solved by just removing crt0.o from the list of files that are to be deleted when creating libcx.a. Andy
janssen@parc.xerox.com (Bill Janssen) (09/28/90)
I have no idea what crt0.o contains in most systems, but it seems to me that it used to contain some useful global variables, such as _onexit, a list of routines to call on exiting from the program. Does 'on_exit(3)' work properly in ATK? Bill
ajp+@ANDREW.CMU.EDU (Andrew Palay) (09/28/90)
The issue here is that crt0.o is linked into runapp and therefore should not appear in libcx.a at all. From what I can tell the code in the Imakefile explicitly puts in crt0.o into libcx.a, only so that it can pull it back out again. This should of course work (and I'm not sure why it isn't on a 5000) but seems rather redundant. Andy