443
edits
-
Changes
no edit summary
The librarian program, LIBR, has the function of com-bining combining several object files into a single file known as a
library. The purposes of combining several such object
modules are several.
*a. fewer files to link*b. faster access*c. uses less disk space
In order to make the library concept useful, it is
necessary for the linker to treat modules in a library dif-ferently differently from object files. If an object file is specified
to the linker, it will be linked into the final linked
module. A module in a library, however, will only be linked
== The Library Format ==
The modules in a library are basically just con-catenatedconcatenated, but at the beginning of a library is maintained a
directory of the modules and symbols in the library. Since
this directory is smaller than the sum of the modules, the
read only the directory and not all the modules on the first
pass. On the second pass it need read only those modules
which are required, seeking over the others. This all minim-izes minimizes disk i/o when linking.
It should be noted that the library format is geared
exclusively toward object modules, and is not a general pur-pose purpose archiving mechanism as is used by some other compiler
systems. This has the advantage that the format may be
optimized toward speeding up the linkage process.
commands to it is as follows:
LIBR k file.lib file.obj ...
Interpreting this, LIBR is the name of the program, k
is a key letter denoting the function requested of the
librarian (replacing, extracting or deleting modules, list-ing listing modules or symbols), file.lib is the name of the library
file to be operated on, and file.obj is zero or more object
file names.
The key letters are:
;r
:replace modules
;d
:delete modules
;x
:extract modules
;m
:list module names
;s
:list modules with symbols
When replacing or extracting modules, the file.obj
arguments are the names of the modules to be replaced or
extracted. If no such arguments are supplied, all the
modules in the library will be replaced or extracted respec-tivelyrespectively. Adding a file to a library is performed by request-ing requesting the librarian to replace it in the library. Since it is
not present, the module will be appended to the library. If
the r key is used and the library does not exist, it will be
Here are some examples of usage of the librarian.
LIBR m file.lib:List all modules in the library file.lib.
LIBR s file.lib a.obj b.obj c.obj:List the global symbols in the modules a.obj, b.obj andc.obj
LIBR r file.lib 1.obj 2.obj:Replace the module 1.obj in the file file.lib with thecontents of the object file 1.obj, and repeat for2.obj. If the object module is not already present inthe library, append it to the end.
LIBR x file.lib:Extract, without deletion, all the modules in file.liband write them as object files on disk.
LIBR d file.lib a.obj b.obj 2.obj:Delete the object modules a.obj, b.obj and 2.obj fromthe library file.lib.
== Supplying Arguments ==
input from the file, without prompting. For example:
LIBR libr> r file.lib 1.obj 2.obj 3.obj \ libr> 4.obj 5.obj 6.obj
will perform much the same as if the .obj files had been
LIBR itself, the remainder of the text was typed as input.
LIBR <lib.cmd
Libr will read input from lib.cmd, and execute the com-mand command found therein. This allows a virtually unlimited length
command to be given to LIBR.
== Listing Format ==
A request to LIBR to list module names will simply pro-duce produce a list of names, one per line, on standard output. The
s keyletter will produce the same, with a list of symbols
after each module name. Each symbol will be preceded by the
The ordering of the modules in a library is significant
to the linker. If a library contains a module which refer-ences references a symbol defined in another module in the same
library, the module defining the symbol should come after
the module referencing the symbol.
