07/07/86 bind, bd Syntax as a command: bd path_specs {-control_args} Function: produces a single bound object segment from one or more unbound object segments, which are called the components of the bound segment. You can use archive segments or unarchived segments to specify pathnames of object components. Arguments: path_specs can be one or more of the following logically concatenated in a left-to-right order to produce a single sequence of input component object segments. -archive PATHs, -ac PATHs indicates that each PATH is the pathname of an archive segment containing one or more object segments. If the .archive suffix does not exist, it is assumed. (All arguments following -archive but preceding the next control argument are considered to be pathnames.) -segment PATHs, -sm PATHs indicates that each PATH is the pathname of a stand-alone segment. The pathname is tried as given, i.e., no suffixes are assumed. (All arguments following -segment but preceding the next control argument are considered to be pathnames.) PATHs functions exactly as -archive PATHs. Control arguments: -bindfile path, -bdf path specifies the name (not pathname) of the bindfile to be used to control the binding process. The suffix .bind is assumed. (See "Notes on bindfile" below.) -brief, -bf suppresses printing of warning messages. -force_order, -fco is equivalent to including a Force_Order statement in the bindfile. Since the need to use Force_Order is often temporary and caused by update archives that have had components deleted, this is preferable to using the Force_Order statement because you need only use it while the temporary condition exists. -force_update path_specs, -fud path_specs is similar in function to -update except that the path_specs (see the path_specs argument above) specified following -force_update need not exist. Any path that exists is treated the same way as for -update and any that doesn't is simply ignored. This is useful for constructing abbreviations used for binding objects that may or may not have update paths in various locations. -list, -ls produces a listing segment whose name is derived from the name of the bound object segment plus a suffix of list. The listing segment is generated to dprint; it contains the bound segment's bind control segment (see "Notes on bindfile"), its bind map, and that information from the bound object segment printed by the print_link_info command. You can't invoke -list with -map. In the absence of -list or -map, no listing segment is generated. -map produces a listing segment (with the suffixes list and map) that contains only the bind map information. It is incompatible with -list. In the absence of -list or -map, no listing segment is generated. -update path_specs, -ud path_specs indicates that the following list of path_specs (see the path_specs argument above) specifies update rather than input object segments. The update object segments are matched against the input object segments by object segment name. Matching update object segments replace the corresponding input object segments; unmatched ones are appended to the sequence of input object segments. If several update object segments have the same name, only the last one encountered is bound into the bound segment. Notes on bindfile selection: As the binder is examining the archive components and loose segments, it is also looking for a bindfile. Any segment whose name ends with the suffix "bind" is considered a bindfile. If you specify -bindfile, only bindfiles by that name are considered and the last one by that name is selected; otherwise the first bindfile found among the input segments and all bindfiles among the update segments are considered and the last one is selected. If more than one bindfile is found among the input segments, the second through last are ignored and generate a warning. Notes on bindfile: The bindfile is a segment containing symbolic instructions that control the operation of the binder. The syntax of the bindfile statements consist of a keyword followed by zero or more parameters and then delimited by a statement delimiter. Master statements pertain to the entire bound object segment; normal statements pertain to a single component object within the bound segment. Master statements are identified by master keywords that begin with a capital letter; normal keywords begin with a lowercase letter. A keyword designates a certain action to be undertaken by the binder pertaining to parameters following the keyword. List of master keywords: Objectname the parameter is the segment name of the new bound object. Order the parameters are a list of objectnames in the desired binding order. In the absence of an order statement, binding is done in the order of the input sequence. If an Order statement is present in the bindfile, every object segment being bound must be mentioned in its parameter list. Force_Order same as Order except that the list of parameters can be a subset of the input sequence, allowing the archive segments to contain additional segments that are not to be bound (e.g., source programs). However, the parameter list must include all segments mentioned in objectname statements. Partial_Order same as Order except that the list of parameters can be a subset of the input sequence; the named objectnames are placed in the bound output segment in the order specified and the remaining objects are placed after those named, in the order of the input sequence. Ignore the parameters can be a subset of the input sequence, indicating objects not to be included in the bound output segment. The ignored objects are still mentioned in the bound segment's source map. Global the single parameter can be retain, delete, or no_link. The parameter selected pertains to all component object segments within the bound segment. A global or explicit statement concerning a single component object or a single external symbol of a component object overrides the Global statement for that component object or symbol. Addname the parameters are the symbolic names to be added to the bound segment. If Addname has no parameters, it adds to the bound segment the segment names and synonyms of those component objects for which at least a single entrypoint was retained. No_Table does not require parameters. It omits from the bound segment the symbol tables from all the component symbol sections containing symbol tables. If you don't give this keyword, all symbol tables are kept. Perprocess_Static does not require parameters. It turns on the perprocess_static flag of the bound segment, which prevents the internal static storage from being reset during a run unit. The Order, Force_Order, and Partial_Order statements are mutually contradictory; only one of these can be present in any bindfile. If you supply no bindfile, the binder assumes default parameters corresponding to the following: Objectname: segment name of the first input archive file. Global: retain; /*regenerate all definitions*/ List of normal keywords: objectname the single parameter is the name of a component object as it appears in the archive segment. The objectname statement indicates that all following normal statements (up to but not including the next objectname statement) pertain to the component object whose name is the parameter of the objectname statement. synonym the parameters are symbolic segment names declared to be synonymous to the component object's objectname. When b is declared to be a synonym for a, references (in the bound components) of the form b or b$x (any x) are resolved during binding by searching for a definition of b or x in component a. You must give the synonym instruction if such references are to be prelinked. The synonym instruction also affects dynamic linking so that if b is a reference name for the bound segment, then references of the form b or b$x are resolved by searching component a. In this case the synonym instruction may reduce the cost of dynamic linking, and it avoids possible ambiguities when two components contain definitions for the symbol b. Take care to state explicitly in a synonym statement all the normally used segment names of a component object. For example, the create and create_dir commands are implemented in one procedure, and both have abbreviations; thus a bindfile for the bound segment in which this procedure resides contains objectname: create; synonym: create, cr, create_dir, cd; Failure to state segment names results in inefficient linker performance. retain the parameters are the names of entrypoints defined within the component object segment that you wish to retain as entrypoints of the bound object segment. delete the parameters are the names of entrypoints defined within the component object segment that you don't wish to be retained as entrypoints of the new bound segment. no_link the parameters are the names of entrypoints that are not to be prelinked during binding. This statement implies that the specified names be retained. The retain, delete, and no_link statements are considered exclusive. An error message is displayed if the binder recognizes that two or more such statements were made regarding any single entrypoint. global the single parameter can be retain, delete, or no_link. The parameter selected becomes effective for all entrypoints of the component object. An explicit retain, delete, or no_link statement concerning a given entrypoint of the component object overrides the global statement for that specific entrypoint. A global no_link causes all external references to the component object to be regenerated as links to entrypoints; this allows execution time substitution of such a component by a free-standing version of it, for example, for debugging purposes. table does not require parameters. It retains the symbol table for the component and is needed to override the No_Table master keyword. List of bindfile delimiters: : keyword delimiter used to identify a keyword followed by one or parameters. A keyword that is followed by no parameters is delimited by a statement delimiter. ; statement delimiter. , parameter delimiter. The last parameter is delimited by a statement delimiter. /* begin comment. / end comment. ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved