Changing symbols to "static"

[John O'Brien]

In article <14294 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:

>You're missing an important point:  spot() REQUIRES that definitions
>be provided for a() and b().  Changing these to private rather than
>global symbols wouldn't magically define suitable functions!  In some
>(non standard conforming) implementations, c and d might already be
>compiled into references to "common" storage, so they would get
>storage defined for them even if there were no explicit definition in
>the set of modules being linked.

Let me try again.  I'm already referring the symbols a,b,c and d from
several places (they are utility functions), so I can't just make them
static.  What I want to do takes two steps.  Assume the file with a, b,
c, and d is named "one.c", and the file with spot is named "two.c" and
both files have been compiled to ".o" files.  The first step is to link
"one" and "two" into another ".o" file:

	ld -r -o big.o one.o two.o

This creates a ".o" file by combining "one.o" and "two.o" into "big.o",
which contains all of the definitions and which has external symbols
a, b, c, d, and spot.  Now, if it is possible to change a, b, c, and d to
"static" class, when another program links in big.o a, b, c, d are not
exported but can be referred to within "big.o".  Nobody ever links in 
more than one pass, so this approach is not commonly understood (by me,
either).

>
>My recommendation is to design the kind of external interfaces you
>really want, rather than trying to override the design via the linker.
This code is here, this code has been extensively tested, this code is
called from many different places.  Part of the design requirements is
that I link in this code and not copy the source (this is to avoid hav-
ing to maintain two pieces of code that do the same thing).

			John