Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!sdd.hp.com!mips!pacbell.com!ucsd!sdcc6!jclark
From: jclark@sdcc6.ucsd.edu (John Clark)
Newsgroups: comp.os.os9
Subject: Re: C Linker Library problems -- help!
Keywords: OSK, C, linker, libraries
Message-ID: <18814@sdcc6.ucsd.edu>
Date: 30 Apr 91 00:06:45 GMT
References: <1991Apr25.175935.8665@cbnewsd.att.com> <196@blars> <1991Apr29.223454.5112@cbnewsd.att.com>
Organization: University of California, San Diego
Lines: 26

In article <1991Apr29.223454.5112@cbnewsd.att.com> knudsen@cbnewsd.att.com (michael.j.knudsen) writes:
+
+> All routines in any one source file are always pulled in as a unit.
+> Confuse, no, but it won't pull the routines apart.
+
+Yep, others have confirmed that this is the problem.  THe bunch of
+functions I'm trying to replace was not intended as a lib and so
+was not MERGEd up.

The 'pulling' out of individual functions was possible in assmebly
files which had individual '.psect's for each function. I have never
used the psect feature of r68?(other than the absolute minimum) so
I can't comment on L68's behavior. But in other systems, one could get
the 'as needed function' extraction behavior mentioned above. As for
a C module with the 'same' feature, is there a compiler directive to
allow each function put into a unique psect. But then what about variables
used by that function. There are a number of complexities which the
'as needed extraction' implies. May be it's better for the
'programmer' to simplify the situation by coding one function per
source file. That has been my policy(where ever possible) for some
time. The main problem is the number of modules. But with 'make' and
appropriate makefiles the problem is managable.
-- 

John Clark
jclark@ucsd.edu