allbery@ncoast.UUCP (Brandon Allbery) (07/06/86)
Expires: Quoted from <1916@brl-smoke.ARPA> ["Unix Makefile"], by CBMurphy@HI-MULTICS.arpa (Cornelia B. Murphy - SCTC)... +--------------- | We recently received the source code for Chris Lewis's version of Ron Cain's | Small-C compiler. We're running on System V and have all the proper | modifications as Chris has instructed. However, when running the | makefile to compile the source, the following sequential makefile lines | generate the following error messages: | | ranlib scclib.a | Make: Cannot load ranlib. Stop. | | ucb ranlib scclib.a | Make: Cannot load ucb. Stop. +--------------- The ``ucb'' program looks like a universe-changing program for something like a Pyramid that supports both BSD4.2 and AT&T SysV simultaneously. If you had that you'd probably know it, so forget it. System V doesn't have ranlib. Just comment out that step; ld can handle archives directly. Under V7 (I think) or System III or Xenix, etc. use the following on the line that builds the archive: ar rcv archive `lorder object-files | tsort` I find it advisable to rm -f archive before this, as ar will ignore the order of files stated by tsort and use that already in the archive, which could cause ld not to see any new files you've added. Summary: System V doesn't need ranlib. [If ld gives you undefined symbol errors, use lorder and tsort on the line where the archive is created.] --Brandon -- ihnp4!sun!cwruecmp!ncoast!allbery ncoast!allbery@Case.CSNET ncoast!tdi2!brandon (ncoast!tdi2!root for business) 6615 Center St. #A1-105, Mentor, OH 44060-4101 Phone: +01 216 974 9210 CIS 74106,1032 MCI MAIL BALLBERY (part-time)
dbr@foxvax5.UUCP (D.B. Robinson ) (07/08/86)
<object library sacrifice>
Now that System V no longer supports ranlib(1), what happens to the code
in libraries that have cycles in their references? By cycles I mean:
file x.c:
rock() {
...
hardness();
...
}
file y.c:
hardness() {
...
rock();
...
}
These sort of things do happen. This is a fairly simple case of
a cycle. Three or more levels can and do happen occasionally.
The lorder(1) and tsort(1) pair that existed previously gave error
messages in this case. Ranlib was a must if you happened to put
the *.o in the opposite order from the call used when linking (i.e.
main() calls hardness(), but x.o is in the archive before y.o).
Are these cases still covered? I expect so, but how?
Douglas Robinson jobs don't kill programmers, programmers kill jobs
The Foxboro Company
MS 04-3A cybvax0!foxvax5!dbr
38 Neponset Avenue
Foxboro, MA 02035 617/543-8750gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/09/86)
In article <292@foxvax5.UUCP> dbr@foxvax5.UUCP (D.B. Robinson (Douglas)) writes: >Now that System V no longer supports ranlib(1), what happens to the code >in libraries that have cycles in their references? No, no -- you misunderstand the situation. UNIX System V does not have a "ranlib" command because it does not need one. The UNIX System V "ar" maintains an entry-point table of contents for the COFF (object module) members, which "ld" uses. This is the *same* scheme as the one using "ranlib", except the table of contents is kept automatically up-to-date by "ar" instead of having to run a separate command afterwards. This is a real win if you copy library archives around, since Berkeley "ld" thinks your new archives are out-of-date if you don't run "ranlib" on the newly-created libraries, whereas the correct information is embedded in the library and follows it around under the System V scheme. Of course, it does uglify the archiver, which acquires special-case code for object-module members.
guy@sun.uucp (Guy Harris) (07/09/86)
> Now that System V no longer supports ranlib(1), what happens to the code > in libraries that have cycles in their references? System V never supported "ranlib", so it's not a question of "no longer". However, it does provide the exact same functionality; it just stuffs it directly into "ar", and calls the symbol table "" rather than "__.SYMDEF". As such, the same thing happens to that code as happens in V7/BSD systems when you use "ranlib". -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
chris@umcp-cs.UUCP (Chris Torek) (07/09/86)
In article <292@foxvax5.UUCP> dbr@foxvax5.UUCP (D.B. Robinson
(Douglas)) asks how System V handles cyclic dependencies if it has
no ranlib command. As I understand it, the System V `ar' has a
`virtual ranlib' built in to it; running `ar' on an object file
(one with an appropriate magic number) automatically builds or
updates the __.SYMDEF archive member. It seems to me that this
is the correct external behaviour: the library builder should
manage its table of contents itself. (I would be just as happy
with a /usr/bin/ar shell script that invoked ranlib when inserting
an object file, although it would probably be slower.)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP: seismo!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.eduwhp@cbnap.UUCP (W. H. Pollock x4575 3S235) (07/10/86)
In article <292@foxvax5.UUCP> dbr@foxvax5.UUCP (D.B. Robinson (Douglas)) writes: ><object library sacrifice> > >Now that System V no longer supports ranlib(1), what happens to the code >in libraries that have cycles in their references? By cycles I mean: > ... ranlib is no longer needed because its job is being done by the new ar, so cycles within a single archive library are indeed covered. The "lorder|tsort" stuff is for efficiency only. A more interesting problem is with cycles between archive libraries. In this case there are two solutions (short of restructuring the libraries); the easy one is to list the offending library twice on the cc (or ld) command line (e.g., "cc ... x.a y.a x.a"). A better solution is to use the "-u<sym>" option to ld, which causes <sym> to be undefined *before* any libraries are scanned. W. H. Pollock, UUCP: ...{ihnp4,cbosgd}!cbnap!whp DELPHI: WHP GEnie: W.POLLOCK "The opinions expressed above are ficticious. Any resemblance to the opinions of persons living or dead is purely coincidental."
guy@sun.UUCP (07/10/86)
> As I understand it, the System V `ar' has a `virtual ranlib' built in > to it; running `ar' on an object file (one with an appropriate magic > number) automatically builds or updates the __.SYMDEF archive member. Yup. The symbol table archive member's name is a null string, rather than "__.SYMDEF". Actually, running "ar" with any command to update the archive, or with the "s" keyletter, builds, updates, or deletes the table-of-symbols member; if there were any object files in the archive, it's installed, otherwise it's not. The temporary intermediate-file version of the archive doesn't have the table of symbols, so if it's not installed it is in effect deleted, so if you have an archive with some object files and some non-object files, deleting all the object files makes the table of symbols disappear. > It seems to me that this is the correct external behaviour: the library > builder should manage its table of contents itself. Yes, it's less error-prone, which is presumably why most other OSes do it this way. (It's not perfect; if you copy an archive file, you have to do "ar ts <archive> >/dev/null" to reconstruct the table of symbols. You could, of course, write a script to do for i in "$@" do ar ts $i >/dev/null done and call it "ranlib".... The 4.3BSD "ranlib" has a "touch" option which merely updates the time on the table-of-symbols member, rather than rebuilding it, which is useful for the case described above.) > (I would be just as happy with a /usr/bin/ar shell script that invoked > ranlib when inserting an object file, although it would probably be slower.) Actually, the equivalent would be a script which ran "ranlib" if 1) any command to update the archive were run or 2) the "s" keyletter were specified. The only differences here would be that the table of symbols would always be installed, whether the archive had any object files in it or not, and would never be deleted. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
guy@sun.UUCP (07/11/86)
> This is a real win if you copy library archives around, > since Berkeley "ld" thinks your new archives are out-of-date > if you don't run "ranlib" on the newly-created libraries, > whereas the correct information is embedded in the library > and follows it around under the System V scheme. Well, more precisely, the correct information is embedded in the library and follows it around under both schemes. However, in the V7 scheme, when you *modify* the library, you have to regenerate the table of contents, while in the S5 scheme, the archiver does it for you. As such, the V7 linker must check to make sure that the modification time of the library isn't more recent than the modification time of the symbol table; unfortunately, this breaks things when you copy libraries. The S5 linker doesn't need to make this check, and doesn't. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
gwyn@brl-smoke.UUCP (07/12/86)
In article <4976@sun.uucp> guy@sun.uucp (Guy Harris) writes: >... (It's not perfect; if you copy an archive file, you have to do >"ar ts <archive> >/dev/null" to reconstruct the table of symbols. ... I know that Guy is seldom mistaken, but I don't understand this at all. I believe that the UNIX System V linker "ld" pays no attention to the mod-time of the library, so it doesn't have the problem that 4BSD has with copied archive files. (I base this on experience with the DMD "m32*" software, which is the only thing I use that is based on COFF.)
guy@sun.UUCP (07/13/86)
> In article <4976@sun.uucp> guy@sun.uucp (Guy Harris) writes: > >... (It's not perfect; if you copy an archive file, you have to do > >"ar ts <archive> >/dev/null" to reconstruct the table of symbols. ... > > I know that Guy is seldom mistaken, but I don't understand this at all. Seldom, maybe, but not never. See subsequent article. > I believe that the UNIX System V linker "ld" pays no attention to the > mod-time of the library, so it doesn't have the problem that 4BSD has > with copied archive files. (Or V7, if you managed to discover "ranlib" and use it; it's there, but undocumented.) Yes, this is correct; since "ar" always regenerates the table of symbols, "ld" assumes that if it exists it's always up-to-date. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
levy@ttrdc.UUCP (07/14/86)
In article <4976@sun.uucp>, guy@sun.uucp (Guy Harris) writes: [about System V ar] >> It seems to me that this is the correct external behaviour: the library >> builder should manage its table of contents itself. > >Yes, it's less error-prone, which is presumably why most other OSes do it >this way. (It's not perfect; if you copy an archive file, you have to do >"ar ts <archive> >/dev/null" to reconstruct the table of symbols. You >could, of course, write a script to do > > for i in "$@" > do > ar ts $i >/dev/null > done > >and call it "ranlib".... The 4.3BSD "ranlib" has a "touch" option >which merely updates the time on the table-of-symbols member, rather than >rebuilding it, which is useful for the case described above.) >-- > Guy Harris > {ihnp4, decvax, seismo, decwrl, ...}!sun!guy > guy@sun.com (or guy@sun.arpa) Ummmm... I beg your royal pardon? Under the System V systems HERE, I am unaware of ever having any reason to update the table of symbols by 'ar ts' or any other method on a copy of an archive ('.a') file for the sake of ld or make or anything else. Please clarify? -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!ttrda!levy
whp@cbnap.UUCP (07/14/86)
In article <1060@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >In article <4976@sun.uucp>, guy@sun.uucp (Guy Harris) writes: >>... (It's not perfect; if you copy an archive file, you have to do >>"ar ts <archive> >/dev/null" to reconstruct the table of symbols. ... >> Guy Harris > >... Please clarify? The only reason to use "ar -ts" on my machine (Sys V 2.0) is after running strip on an archive library; we run strip to remove the debugging info included when compiling with the "-g" option. As strip does remove the table of contents, "ar -ts" must be used to restore it. This may change under newer versions of unix - the mod time on libraries is probably important with unixs that allow shared libraries (Sys V 3.0??). W. H. Pollock, UUCP: ...{ihnp4,cbatt}!cbnap!whp DELPHI: WHP GEnie: W.POLLOCK "The opinions expressed above are ficticious. Any resemblance to the opinions of persons living or dead is purely coincidental."