gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/19/88)
In article <283@ontenv.UUCP> soley@ontenv.UUCP (Norman S. Soley) writes: >... The documentation says that you can add >the object files to the libc.a library (fine OK, I can do this) but >then says some systems may require a rebuild of the symbol table after >doing that and suggests ranlib (which I don't have), I've RTFMed for >ar and ld and can see no answers there, any suggestions? Unless the linker complains about the archive (libc.a) symbol table being out of date, you don't need to do anything about it. I know of four object archive schemes in use on UNIX variants: 1. No symbol table. In this case, be sure the added modules occur physically before any other external data or functions they reference. 2. Automatic symbol table maintenance when an object module is added to the archive. AT&T's recent releases of UNIX System V take this approach, although not every system derived from those releases uses it. 3. Manual symbol table update via "ar ts". I've only seen this on Silicon Graphics Iris workstations but it may be used elsewhere. 4. Manual symbol table update via "ranlib". This is usually the case for systems derived from a Berkeley release. I think "ranlib" originated on 7th Edition UNIX. It's a pain.
pjh@mccc.UUCP (Pete Holsberg) (08/02/89)
Some recently posted programs have requested the use of 'ranlib' but my 3B2/400 SV R3.1 doesn't have it. Wjat is 'ranlib'? What can I use as a work-around? Thanks, Pete -- Pete Holsberg -- Mercer College -- Trenton, NJ 08690 ...!rutgers!princeton!njsmu!mccc!pjh
guy@auspex.auspex.com (Guy Harris) (08/04/89)
>Some recently posted programs have requested the use of 'ranlib' but my >3B2/400 SV R3.1 doesn't have it. > >Wjat is 'ranlib'? A program that adds a "table of contents" as the first member of an archive; said "table of contents" basically lists external symbol definitions from members of the archive that are object files, and gives a pointer to the archive member that defines them. The equivalent program in System V is called "ar"; it automatically reconstructs a table-of-contents member every time you modify the archive. >What can I use as a work-around? Change the Makefile to have # # For BSD (and V7? - it was there, but I don't know how well it # worked) systems, uncomment the "RANLIB=ranlib" line. # For S5 systems (and S3 systems), uncomment the "RANLIB=:" line. # #RANLIB=ranlib #RANLIB=: at the beginning (or wherever the other configuration instructions were put - if somebody posts a program, there *should* be configuration instructions unless they've only gotten it to work on one particular UNIX version), and replace all other occurences of "ranlib" with "$(RANLIB)". That way, on S5 systems, "ranlib" will be defined as ":", which is a do-nothing command.
scott@dtscp1.UUCP (Scott Barman) (08/04/89)
In article <457@mccc.UUCP> you write: >Some recently posted programs have requested the use of 'ranlib' but my >3B2/400 SV R3.1 doesn't have it. > >Wjat is 'ranlib'? What can I use as a work-around? For SV, I use the following to build a library: ar cuv libwhatever.a `lorder *.o | tsort` lorder(1) exists under bsd but is really not necessary with ranlib. -- scott barman {gatech, emory}!dtscp1!scott
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/04/89)
In article <457@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes: >Some recently posted programs have requested the use of 'ranlib' but my >3B2/400 SV R3.1 doesn't have it. >Wjat is 'ranlib'? What can I use as a work-around? "ranlib" was a utility supplied with 7th Edition UNIX that added or updated a special archive member that constituted a table of entry points for the object modules contained in the archive. System V "ar" takes care of this automatically and so there is no need for a separate "ranlib" operation on System V. If you have a sensible Makefile, it will use a symbolic name like RANLIB which you can set to e.g. "echo" or ":" for System V.
rsalz@bbn.com (Rich Salz) (08/04/89)
In <10659@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >.... System V "ar" takes care of this >automatically and so there is no need for a separate "ranlib" operation on >System V. The only problem with this is that there is just no way to shut it off. In building a fairly library (400 files in 20 directories) as much as one-third of our time is wasted by doing all that ranlib stuff for every single file. At least in the BSD scheme I can just do it once after I've put the bulk of the library together. /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/04/89)
In article <1920@prune.bbn.com> rsalz@bbn.com (Rich Salz) writes: -In <10659@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: ->.... System V "ar" takes care of this -The only problem with this is that there is just no way to shut it off. Doesn't the "q" option do that? Seems like it should.
rsalz@bbn.com (Rich Salz) (08/04/89)
In article <1920@prune.bbn.com> I wrote that the builtin table of contents (TOC) stuff makes building large libraries take too long. In <10663@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >Doesn't the "q" option do that? Seems like it should. I'm not sure, but it seems that "q" just zaps the module at the end of the file, but still rebuilds the TOC anyway. Even if it works/worked right, however, it still doesn't solve my problem. I've got a big library (400 files in 20 directories) and I'm going to be replacing about 20 modules (scattered over, say, 10 directories) in that library. About a half-hour of time is WASTED as "ar" creates a TOC 10 times. It would be much more effective if I could NOT build the TOC until the end. I used to agree that having ranlib as a separate command was a real crock, but then I had to use the SysV-oid version of ar... /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
karl@haddock.ima.isc.com (Karl Heuer) (08/04/89)
In article <867@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: >lorder(1) exists under bsd but is really not necessary with ranlib. Conversely, ranlib is not really necessary if you have lorder and tsort. (If tsort reports a circular dependency, the solution is to merge the objects in question into a single module, either with `ld -r' or by recompiling them as a single source.) Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint Followups to comp.unix.questions only; this isn't a C issue.
guy@auspex.auspex.com (Guy Harris) (08/05/89)
>->.... System V "ar" takes care of this >-The only problem with this is that there is just no way to shut it off. > >Doesn't the "q" option do that? Seems like it should. Perhaps it should, but I checked the code, and it doesn't; the "rebuild the symbol table" operation is performed whenever any operation that updates the archive is performed ("ar d", "ar q", "ar m", and "ar r", as well as "ar s" which *just* updates the symbol table). I would prefer it that way - you may not want to update the archive with "ar q" (since it can only be used to *add* members to an archive, not replace existing members, nor move members, nor delete members), so a "don't update the symbol table" feature needs to be a modifier applicable to all such commands; given that, I'd prefer to have *all* operations that update the archive update the symbol table by default, to follow the Principle of Least Surprise. Updating the table of contents on all operations that update the archive isn't a problem if you update the library in one command, rather than e.g. replacing each library member with a separate "ar" command; I think, in fact, that the latter would even be faster with versions of "ar" that *don't* automatically update the symbol table. I can appreciate that it might be less convenient to do so, though....
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (08/05/89)
? From: Doug Gwyn <gwyn@smoke.brl.mil> ? Date: 4 Aug 89 01:37:32 GMT ? In article <1920@prune.bbn.com> rsalz@bbn.com (Rich Salz) writes: ? -In <10659@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: ? ->.... System V "ar" takes care of this ? -The only problem with this is that there is just no way to shut it off. ? Doesn't the "q" option do that? Seems like it should. I dunno. But the last time I asked you that question, you indicated that it did not. RTFS and let us know. Root Boy Jim Have GNU, Will Travel.
chris@cetia.UUCP (Chris Bertin) (08/07/89)
> In article <1920@prune.bbn.com> I wrote that the builtin table of contents > (TOC) stuff makes building large libraries take too long. > > It would be much more effective if I could NOT build the TOC until the > end. I used to agree that having ranlib as a separate command was a real > crock, but then I had to use the SysV-oid version of ar... > /r$ I modified ar.c, ages ago, to recognize the environment variable 'RANLIB'. If this variable is set to 'noauto', the TOC update is not done. With the same modification, if you link ar to ranlib, it will do the TOC update only. I thought the environment variable approach was more portable than adding a flag, since it would just be ignored if ar did not know about it. I compile everything large with: AR="RANLIB=noauto ar" and then do the following when I need to use the libraries: @[ -z "`type ranlib`" ] || ranlib xyz.a Here is a context diff of the changes. --------------------------------------------------------------------------- *** /tmp/geta19136 Mon Aug 7 11:03:07 1989 --- /tmp/getb19136 Mon Aug 7 11:03:07 1989 *************** *** 131,138 **** int (*comfun)(); - main(argc, argv) int argc; char **argv; --- 131,140 ---- int (*comfun)(); + int quick; + char *rl = "ranlib"; + extern char *getenv(); main(argc, argv) int argc; char **argv; *************** *** 143,148 **** --- 145,163 ---- for (i = 0; signum[i]; i++) if (signal(signum[i], SIG_IGN) != SIG_IGN) signal(signum[i], sigdone); + if (!strcmp(cp = *argv, rl) || + ((cp = strrchr(*argv, '/')) && !strcmp(cp+1, rl))) { + if (argc != 2) { + fprintf(stderr, "Usage: %s lib\n", cp); + exit(1); + } + arnam = argv[1]; + mksymtab(); + done(0); + } + if ((cp = getenv("RANLIB")) != NULL && + (!strcmp(cp, "noauto") || !strcmp(cp, "NOAUTO"))) + quick++; if (argc < 3) usage(); cp = argv[1]; *************** *** 224,230 **** update = (flg['d' - 'a'] | flg['q' - 'a'] | flg['m' - 'a'] | flg['r' - 'a'] | flg['u' - 'a'] | flg['s' - 'a']); (*comfun)(); ! if (update) /* make archive symbol table */ mksymtab(); done(notfound()); } --- 239,245 ---- update = (flg['d' - 'a'] | flg['q' - 'a'] | flg['m' - 'a'] | flg['r' - 'a'] | flg['u' - 'a'] | flg['s' - 'a']); (*comfun)(); ! if (update && !quick) /* make archive symbol table */ mksymtab(); done(notfound()); } --------------------------------------------------------------------------- -- Chris Bertin | -- CETIA -- 150, Av Marcelin Berthelot, Z.I. Toulon-Est +33(94)212005 | 83088 Toulon Cedex, France | inria!cetia!chris #! r
rsalz@bbn.com (Rich Salz) (08/07/89)
In article <867@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: >lorder(1) exists under bsd but is really not necessary with ranlib. In <14194@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >Conversely, ranlib is not really necessary if you have lorder and tsort. Nope. To use lorder/tsort you need to have all the .o files around, while ranlib just needs the .a and space to make a new one. Also, on some systems the result of doing ar r lib.a `lorder ... | tsort` makes a commandline that's too big (hint: think lots of directories). /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (08/09/89)
? From: Karl Heuer <karl@haddock.ima.isc.com>
? In article <867@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes:
? >lorder(1) exists under bsd but is really not necessary with ranlib.
? Conversely, ranlib is not really necessary if you have lorder and tsort.
? (If tsort reports a circular dependency, the solution is to merge the objects
? in question into a single module, either with `ld -r' or by recompiling them
? as a single source.)
Or search the library as many times as the longest cycle :-)
? Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
? Followups to comp.unix.questions only; this isn't a C issue.
Root Boy Jim
Have GNU, Will Travel.