guy@sun.uucp (Guy Harris) (07/04/86)
> ...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. "ranlib" is done automatically by the System V "ar" command. The "ucb ranlib" must be there for the benefit of Pyramid systems, where you must prefix the name of any command not found in System V, but found in 4.2BSD, with "ucb" if you are running in the System V universe (don't ask). This is a tad bizarre; either 1) in the S5 universe, "ar" doesn't generate a table of contents, in which case why the heck isn't "ranlib" accessible in both universes, or 2) in the S5 universe, "ar" *does* generate a table of contents, in which case why the heck are they bothering with "ranlib"? In short, blow both the "ranlib" lines away; you don't need them. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
csg@pyramid.UUCP (Carl S. Gutekunst) (07/07/86)
In article <1916@brl-smoke.ARPA> Cornelia B. Murphy writes: >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. In article <4782@sun.uucp> guy@sun.uucp (Guy Harris) writes: >"ranlib" is done automatically by the System V "ar" command. > [... explanatory comments about Pyramid systems deleted ...] >In short, blow both the "ranlib" lines away; you don't need them. Not quite. Here's the section of Chris's makefile that's causing the problem: #Alternately, you may have to do an lorder $(LIB): $(FE) -ranlib $(LIB) -ucb ranlib $(LIB) Chris got lazy. This is a hazard when using a UNIX(R) port that mixes Berkeley and AT&T, but usually less of a problem on dual-port operating systems like Pyramid OSx, Apollo Domain/IX, and Ridge ROS. Dual-port systems keep all (or most of) the utilities from both systems available in parallel directory trees, but when you run in one "universe," a prefix command ('ucb' and 'att' on the Pyramid) is required to reference commands in the other. Archive files need to be properly ordered for one-pass access by ld(1). In System V.0, the correct way to do this to use the lorder(1) and tsort(1) utilities to construct the argument list to ar: ar cr archive `lorder *.o | tsort` Starting with (I think) System V.1, ar(1) does the sort internally, so funny arguments to ar(1) are unnecessary. Hence Guy's statement is true, but only on more recent versions of System V. Berkeley went a different route, as usual. :-) ranlib(1) is a standard 4.2bsd utility that both sorts the archive, and prepends a table of contents. It doesn't exist in any stock System V port. Chris's machine is a Pyramid 90x running OSx 2.5, which supports System V.0 and 4.2bsd. So his AT&T ar(1) doesn't do the sort. But he should have used ar `lorder|tsort`, not ranlib. Chris's one-line comment implies that he knew he was doing something that was non-portable, but for whatever reason he went ahead with it. Since he usually does an outstanding job, I'm a bit surprised he made this blunder, but I'm not going to flame him for it. :-) -- Carl S. Gutekunst {allegra,cmcl2,decwrl,hplabs,ut-sally,utzoo}!pyramid!csg Pyramid Technology Corp, Mountain View, CA +1 415 965 7200
guy@sun.UUCP (07/07/86)
> Starting with (I think) System V.1, ar(1) does the sort internally, so funny > arguments to ar(1) are unnecessary. Hence Guy's statement is true, but only > on more recent versions of System V. I.e., it's not true on System V.-1? System V.1 was the first System V release, so I'm not sure what less-recent versions you're referring to. BTW, S5's "ar" doesn't sort the archive, it just prepends a table of contents which is similar to the "ranlib" one. > Berkeley went a different route, as usual. :-) Wrongo. "ranlib" comes from an AT&T UNIX - V7. (Note the use of "an" before "AT&T UNIX" - there is no unique referent for the term "AT&T UNIX".) > ranlib(1) is a standard 4.2bsd utility that both sorts the archive, and > prepends a table of contents. No, it doesn't sort the archive. It just prepends a table of contents which is similar to the one prepended by S5's "ar". > It doesn't exist in any stock System V port. It could, though; it would just have to be a shell script which did for i in "$@" do ar ts $i >/dev/null done which would, like the V7/4BSD "ar", regenerate the table of contents for each archive given as an argument. Doing so in a system intending to support both environments would mean a "Makefile" from a 4.2BSD environment would be more likely to work in either environment. > Chris's machine is a Pyramid 90x running OSx 2.5, which supports System V.0 > and 4.2bsd. What is "System V.0"? There was a release called just System V, followed by a release called System V Release 2. That first release was either System V Release 0 (release names have to be comprehensible to non-C programmers, so they tend not to be 0-based, making this unlikely) or System V Release 1. In either case, *both* release most definitely *did* support the table-of-contents generation. The S5R1 version had a portable archive format which was completely different from the 4BSD version; they came to their senses in S5R2 and adopted the 4BSD version with a minor change (archive member names are padded with '/', not ' '). > So his AT&T ar(1) doesn't do the sort. But he should have used > ar `lorder|tsort`, not ranlib. The former will work in either environment, although if "ld" is the 4BSD version it will give a warning if the table of contents is absent. It's unlikely that the target system uses two different object file formats in the different environments, as that is likely to lead to endless confusion (and higher costs to support the OS, as you have to support two assemblers *and* possibly two compilers, two linkers, two archivers, two "nm"s, two "strip"s, etc.). If the target system uses the 4BSD object file format, either 1) the "ar" in the S5 environment can have "ranlib" built into it (be careful, though - "ranlib" adds a table of contents regardless of whether the archive contained any object files or not - "ar ?s" shouldn't do so unless the archive contains object files), so that if the command updates the archive or if the "s" key is specified, the table of contents (member name "__.SYMDEF") will be updated, or 2) the "ranlib" program should be available in the S5 environment. (This requires S5 Makefiles to be updated; however, if you're using the 4BSD object file tools, the ones which use COFF-specific features will have to be updated anyway.) If the target system uses the COFF, there should only be one "ar", which should be the S5 one, in which case there's no need for "ranlib", but it should be supplied as described above so that 4BSD Makefiles will work with relatively little change (although, again, if they rely on features specific to pre-COFF systems, they may have to change). -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
narayan@wg3b20.UUCP (The Champ) (07/08/86)
> > ...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. > Link /bin/echo to /bin/ranlib This will save you from modifying make sources. -- Narayan Mohanram Phone: 415-962 7170 ARPANET wg3b20!narayan@lll-tis-b.ARPA Usenet ihnp4!{amdahl,pesnta}!wg3b20!narayan Mail The Wollongong Group 1129 San Antonio Road Palo Alto, CA 94303. USA ========================================================= || If you can't lick it, try some whipped cream || =========================================================