lorder bug (doesn't see global ints).
Guy Harris
> (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'.
That's odd:
1) System V has "ranlib" built into "ar", so the only thing "lorder" should
do is perhaps make "ld" run faster.
2) The 4.2BSD "lorder" has "/[TD] /" on line 19.
3) The System V, Release 2 "lorder" doesn't have "/[TD] /" anywhere in it,
and line 19 is in the middle of a comment.
Did you do the "lorder"ing on a 4.2 or an S5 machine? If the latter, you
don't have the S5 "lorder", and probably don't have the S5 object file
format. You might have "ranlib", though; try running "ranlib" on the
library. (There may, in fact, be a bug in "lorder" on 4.2, but not one that
causes problems since everybody "ranlib"s their libraries. I think that
"lorder" dates back to V7, which had a "ranlib" as well but didn't document
it and didn't use it on "libc".)
--
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
g...@sun.com (or g...@sun.arpa)
Sam Kendall
>> 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 s...@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 s...@godot.think.com
Thinking Machines Corp. ihnp4!think!sam
Sam Kendall
>and line 19 is in the middle of a comment.
No, actually, there are two different SVR2 lorders. Originally, as I
reconstruct it, the COFF was put in place, along with a new and totally
different output format for nm(1). Then two different groups went off
to make System V's, and each independently found that the new nm format
broke the lorder shell script. The two groups solved it in different
ways: one group added an undocumented nm option to produce old-style
output, so that lorder could remain basically unchanged. The other
group rewrote lorder to use the new nm output format; and it can't
have been easy, because the new format is complicated and poorly
documented.
Anyway, on the 3B20 (and VAX?) lorder _does_ have "/[TD] /" in it, and
nm has the undocumented compatibility option; but on the 3B2 lorder
does not have "/[TD] /", and nm does not have the option. (It's
possible I have the 3B20 and 3B2 reversed here.)
Guy Harris
Not on the VAX, or at least not on System V, Release 2, (Version 1) for the
VAX.