🚀 go-pugleaf

In article <6425@sun.uucp> guy@sun.uucp (Guy Harris) writes:
>> Anyway, while creating the libraries, I noticed something was awry
>> (mainly 'cos the damn thing wouldn't compile!) and I narrowed the problem
>> down to the fact that lorder doesn't spot global ints when making its
>> dependency decisions. This is because nm flags these symbols as 'C'.

I (as sam@delftcc.UUCP) posted a fix to this a while ago, probably
sometime last year.  I don't have the fix handy.  Guy is right that
this bug shouldn't affect System V, although there really is a bug in
lorder.

On pre-COFF (AT&T Common Object File Format) UNIX systems, these are the
meanings of symbol types output by nm(1):

	Letter	Meaning				C example
	-----   -------				---------
	 U	Undefined			extern int i;
	 C	Common (in the Fortran sense)	int i;
	 D	Definition			int i = 5;
	 T	Text				f(){}
	 B	BSS (initialized to 0)		int i; after ld-ing

A 'C' symbol results from a noninitialized declaration of a global
variable.  'C' symbols appear only in relocatable object files.  Here
are a the rules for how ld(1) combines 'C' symbols:

	U* + C* + D => D
	U* + C*     => B

In other words, when any number of 'U's and 'C's combine with a 'D',
then the 'D' becomes the defining instance; but when any number of 'U's
and 'C's combine alone, the largest 'C' becomes the defining instance,
and the symbol is made into a 'B'.

The bug in lorder is that it recognizes only two classes of symbols for
the purposes of partial ordering: 'T' and 'D', and everything else.
But 'C' forms a middle class: symbols should be ordered 'U' first, then
'C', then 'T' or 'D'.

In putting the fix into lorder, you need to add a third temporary file,
and then run three joins instead of one.

---
Sam Kendall			sam@godot.think.com
Thinking Machines Corp.		ihnp4!think!sam