Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!husc6!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.software-eng
Subject: Re: Question Re: Configuration Management
Message-ID: <697@cresswell.quintus.UUCP>
Date: 26 Feb 88 10:26:04 GMT
References: <497@aimt.UUCP> <2640@ihlpe.ATT.COM> <188@dinl.mmc.UUCP> <2323@geac.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 93
Keywords: linkers, software design, Unix as a religion
Summary: states of the art

In article <2323@geac.UUCP>, daveb@geac.UUCP (David Collier-Brown) writes:
>    Both Mike (politely) and Chris (substantially less so) miss the
> point that the Unix linker was a conscious cheap-and-dirty.  The Multics
> system avoided the whole IDEA of static linkers[1], and most if not
> all commercial systems not derived from Unix have better linkers.
> Good Lord, the IBM /360 had a better linker than Unix! (And I
> wouldn't recommend the /3sickly and its linker to my worst enemy).  
> 
I suggest that you take a look at some of the limits of the /360 linker
(e.g. number of entry points per load module).  If you want overlays,
it may well be just what you want.  (The BSD ld(1) is definitely not
state-of-the-art with respect to overlays.  Thank goodness.)

The problem is not the UNIX **linker**.  ld(1) is perfectly capable of
pulling out just the pieces it needs *IF IT IS GIVEN THE RIGHT KIND OF
FILE*.  The problem is the UNIX **compilers**, which don't generate
that sort of file.  There is no reason in principle why the Fortran
compiler, for argument's sake, couldn't generate a '.a' file instead
of a '.o' file.  In fact you can hack that with a shell script:

	#!/bin/sh
	#   NAME:  fca
	#   SYNOPSIS:  fca x.f y.f ....
	#   DESCRIPTION: much the same as f77 -c x.f y.f ...
	#   except that it generates .a files rather than .o files
	#   BUGS: this thing does NO error checking at all!
	#
	Directory=tmp$$
	mkdir $Directory
	cd $Directory
	for File in $*
	    do
		(cd .. ; cat $File) | fsplit
		f77 -c *.f
		Archive=../`basename $File .f`.a
		if -f $Archive 
		    then
			rm $Archive
		    fi
		ar q $Archive *.o
		rm *.o
		ranlib $Archive
	    done
	cd ..
	rm -r $Directory
	exit

What's the problem with doing this to C?  Well, what do you do with
static variables and functions?  (If you can solve this, you can solve
the "shared literals" problem.)  The problem is that if a C source
file is split into pieces (separately loadable segments), the static
variables and functions must be visible to other pieces *from the
same source file*.  So you need THREE levels of names:

    --	names which are strictly local to a single segment (e.g. labels,
	static variables inside functions)

    --	names which are visible within a cluster of segments, but
	not outside that cluster (e.g. shared literals, static
	variables and functions at file level)

    --	names which are visible between clusters.

ld(1) only provides two levels of names.  The missing level could be
simulated by taking a timestamp and the cpuid and using them as a
prefix.  For example,
	static int fred;
might turn into
	M.1200005b22254953.fred
{that's what
	/* do this once per source file */
	sprintf(prefix, "M.%8lx%8lx.", gethostid(), time((long*)0));
	/* do this once per file-level static symbol */
	printf("%s%s\n", prefix, "fred");
 just printed on my terminal.
}
This is not entirely satisfactory, and requires a loader without any
stupid restrictions on the lengths of names (NOT one of the /360's
features...), but combining this with the fca script above shows that
there is no reason why a UNIX compiler could not provide the required
feature without requiring any change to the loader.  Of course, the
debuggers might give you some trouble too...

How about someone providing this as an option in GNU CC?

I know that some other loaders also support only two levels of names.
It wouldn't surprise me if the VMS loader supported three.  But since
most old loaders were developed with Fortran and such in mind, and since
Fortran only needs two levels of names, I'd be surprised if many of them
had the three levels that C needs.

We could profitably turn this into a survey of what the linker
requirements of various languages are:  could an ADA compiler easily
use the UNIX / VMS / MVS / PR1MOS linker?