HP 3000 Manuals HP 3000 Manuals
Operation
The following sections explain how to create dynamically or statically
linked executable modules and dynamically loadable modules. How to
statically link the compiler with other programs is also described.
Creating Dynamically Linked Executable Modules
Dynamically linked executable modules are created using the -x and the -B
dynamic or +B dynamic flags on the cob command line (full details on the
-x and -B and +B flags are contained in Appendix D , Descriptions of
cob Flags):
cob -x file-names -B dynamic
where:
file-names are the files input to the cob command.
This creates a dynamically linked executable module. On environments
where dynamic linking is supported, -B dynamic is the default, so it need
not be specified on the command line.
The cob processing involved in creating this type of module is as
follows:
1. source files with extension .cbl are compiled to intermediate code
(.cbl to .int)
2. intermediate code files are generated to object modules (.int to
.o)
3. object modules are linked (.o to a.out)
This produces a statically linked executable file which uses dynamic
linking of shared libraries.
Note: cob performs all of this processing automatically if the -x flag
is set; however, you can perform any of these steps manually by
specifying the appropriate cob flag (see Appendix D ,
Descriptions of cob Flags).
Any object (.o) files are passed to the system linker (ld) in the order
in which they and any options passed to ld were specified on the command
line (except for the +l and +L flags; see Appendix D , Descriptions of
cob Flags). Any files input to the cob command which were not .o files
are replaced (in the same logical position on the command line) with
their mapped .o files. Only .o or .a input files, input files which map
to .o files, or unrecognized files or options are passed to ld. The
default entry point is the base-name of the first input file.
For example, the cob processing for a source file named myfile.cbl input
to the cob command with the -x flag set is:
myfile.cbl -> myfile.int -> myfile.o -> myfile
where the final myfile is an a.out type module.
When creating a dynamically linked executable module, any modules that
are held in shared objects are not linked into your executable module.
Instead, if a module is referenced at run time, then the shared object is
loaded into memory and run.
Shared object libraries are used in preference to any archive libraries.
If any named library does not have a corresponding shared object, the
appropriate archive will be statically linked instead.
For example, if you specify two libraries, abc and xyz, on the cob
command line as follows:
cob -x prog.cbl -labc -lxyz
and the libraries xyz.so, xyz.a and abc.a exist, then the shared object
xyz.so will be dynamic linked, and the archive abc.a will be static
linked. For information on how to create shared objects or archives, see
your operating system documentation.
Creating Statically Linked Executable Modules
Statically linked executable modules are created using the -x and the -B
static or +B static flags on the cob command line (full details on the -x
and -B and +B flags are contained in Appendix D , Descriptions of cob
Flags):
cob -x file-names -B static
where:
file-names are the files input to the cob command.
This creates a statically linked executable module with the base-name of
the first file input to the cob command with no extension.
Note: The -B flag is not supported on UNIX operating systems that do
not support dynamic linking. If your system does not support
it, then do not specify the -B static flag on the cob command
line.
The cob processing involved in creating this type of module is as
follows:
1. source files with extension .cbl are compiled to intermediate code
(.cbl to .int)
2. intermediate code files are generated to object modules (.int to
.o)
3. object modules are linked (.o to a.out)
This produces a statically linked executable file which uses dynamic
linking of shared libraries.
Note: cob performs all of this processing automatically if the -x flag
is set; however, you can perform any of these steps manually by
specifying the appropriate cob flag (see Appendix D ,
Descriptions of cob Flags).
Any object (.o) files are passed to the system linker (ld) in the order
in which they and any options passed to ld were specified on the command
line (except for the +l and +L flags; see Appendix D , Descriptions of
cob Flags). Any files input to the cob command which were not .o files
are replaced (in the same logical position on the command line) with
their mapped .o files. Only .o, .a or .so input files, or input files
which map to .o files, are passed to ld. The default entry point is the
base-name of the first input file.
For example, the cob processing for a source file named myfile.cbl input
to the cob command with the -x flag set is:
myfile.cbl -> myfile.int -> myfile.o -> myfile
where the final myfile is an a.out type module.
When creating a statically linked executable module, any modules that are
held in archives are linked into your executable module only if they are
referenced. For CALL DATANAME, names of the CALL targets are not known
at link time. If you want to link modules that are called by DATANAME
rather than by literal, you must use one of the following methods. Both
examples assume that routines rtn1, rtn2, ..., rtnn are defined in the
library lib and that rtn1 and rtn2 are called by data name.
* Create a dummy C source file containing calls to these modules of
the form:
dummy(){
rtn1();
rtn2();
:
:
rtnn();
}
then link this dummy file with the remaining modules, as follows:
cob -x -llib prog.cbl dummy.c
or
* use the -I cob flag (see Appendix D , Descriptions of cob
Flags) to include the routines as follows:
cob -x -llib prog.cbl -I rtn1 -I rtn2
If you are linking a large number of routines or large object modules,
you should be aware of the following:
* If you are trying to link a large number of user routines to the
RTS, you may exceed the system linker limits. To overcome this,
you can partially link modules with the system linker (ld -r)
command. You can then link these partially linked modules to the
RTS in the usual way by specifying the -x cob flag.
* In some environments it may be necessary to increase the operating
system parameter ulimit to allow linking of large object modules.
This is necessary if your system linker cannot automatically
override the ulimit on your machine. You should set ulimit to the
size of the largest executable module you expect to produce.
Creating Dynamically Loadable Executable Files
Dynamically loadable executable files are created using the -u flag on
the cob command line:
cob -u file-name
where
file-name is a file input to the cob command.
The cob processing involved in creating this type of module is source
files are compiled (.cbl to .int) and code generated (.int to .gnt).
For example, the cob processing for a source file named myfile.cbl input
to the cob command with the -u flag set is:
myfile.cbl -> myfile.int -> myfile.gnt
As the first step in this procedure is the same as that for producing a
statically linked executable file, it may be omitted if a valid .int file
already exists and is specified on the cob command line instead of the
.cbl file.
Statically Linking the Compiler
The Micro Focus COBOL system provides you with the ability to statically
link the compiler with other programs. This will enable you to call
preprocessors written in C, for example.
In order to do this the system administrator can run the supplied script
file, mkcobol, in the $COBDIR/src/cobol directory, having first logged on
as root and ensured that all the programs to be linked to the compiler
have been moved to the $COBDIR/src/cobol directory.
To run mkcobol the system administrator should enter:
mkcobol file-names
where:
file-names are the names of the source and/or object files to
be linked to the compiler.