adam@gec-mi-at.co.uk (Adam Quantrill) (08/20/86)
Apologies if someone has fixed this before, but here goes...
I've got the onerous task of porting some of our crashware from
its nice, safe home on 4.2BSD to horrible sysV (flame flame!! 8^).
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'.
Here's the fix:
--------8><-------cut-here----------8><--------------
19c
/[TDC] /{
.
w
q
--------8><-------cut-here----------8><--------------
Run it via ed on the lorder shell script. If you use bss symbols (whatever
they are) you may wish to add a 'B' after the 'C' above. I've even put in the
w q for the lazy amongst us!
P.S. - Does this make me a wizard?guy@sun.uucp (Guy Harris) (08/22/86)
> 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'. 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 guy@sun.com (or guy@sun.arpa)
sam@think.COM (Sam Kendall) (08/22/86)
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