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