HP 3000 Manuals HP 3000 Manuals
Operation
The following sections explain how to create dynamically or statically
linked executable modules and dynamically loadable modules.
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 the appendix 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 the appendix Descriptions
of cob Flags).
Any object (.o) filesare 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 the appendix 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 typemodule.
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 `libxyz.so, libxyz.a and libabc.a exist, then the
shared object libxyz.so is dynamic linked, and the archive libabc.a is
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 the appendix 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 the appendix Descriptions
of cob Flags).
Any object (.o) filesare 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 the appendix 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 typemodule.
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 the appendix Descriptions of cob Flags)
to include this routine 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 enable 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.
* The program name is used as the initial entry point name. On file
system that support long file-names, if the program name is longer
than the entry point name limit, then the program name is
truncated to this limit. Therefore, you are strongly recommended
to keep the length of program source file-name below the entry
point name limit. See also the appendix System Limits and
Programming Restrictions.
Creating Dynamically Loadable Executable Files
Dynamically loadable executable files are created using the -u flagon 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
The first step in this procedure is the same as that for producing a
statically linked executable file. So, it may be omitted if a valid .int
file already exists and is specified on the cob command line instead of
the .cbl file.
On file systems that support long file-names, file-names for programs
that are to be dynamically loadable must be unique in the first 30
characters. This is because file-names longer than the entry point name
limit are truncated to that limit when statically linked or dynamically
loaded. Therefore, you are recommended to keep program source file-names
below 30 characters in length. See also the appendix System Limits and
Programming Restrictions.